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Hamburg (die Dezentrale) Lokstedter Weg 72 » 2. bis 5. Dienstag im Monat ab etwa 20 Uhr http://hamburg. 
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hannover.ccc.de/ 
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Köln, Chaos Computer Club Cologne (C4) e.V. Chaoslabor, Vogelsanger Str. 286 » Letzter Donnerstag im 
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München, muCCC e.V. Kellerräume in der Blutenburgstr. 17 » 2. Dienstag im Monat ab 19:30 Uhr http:// 
www.muc.ccc.de/ 

Ulm Cafe Einstein an der Uni Ulm » montags ab 19:30 Uhr http://ulm.ccc.de/ mail@ulm.ccc.de 
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Termine auf Webseite http://www.cngw.org/ 

Aus Platzgründen können wir die Details aller Chaostreffs hier nicht abdrucken. Es gibt aber in den folgenden Städten 
Chaostreffs mit Detailinformationen unter http://www.ccc.de/regional/ : Aachen, Bad Waldsee, Basel, Bochum, Darmstadt, 
Dortmund, Dresden, Frankfurt am Main, Freiburg im Breisgau, Cießen/Marburg, Hanau, Heidelberg, Ilmenau, Mainz, 
Mülheim an der Ruhr, Münster/Osnabrück, Offenbach am Main, Paderborn, Regensburg, Stuttgart, Trier, Weimar, 
Wuppertal. 

Friends £ Family 

Zur näheren Chaosfamilie zählen wir (und sie sich) die Häcksen (http://www.haecksen.org/), den/der "Verein zur Förderung 
des öffentlichen bewegten und unbewegten Datenverkehrs e.V." - FoeBuD (http://www.foebud.de/), den Netzladen e.V. in 
Bonn (http://www.netzladen.org/) und die c-base Berlin (http://www.c-base.org/). 
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GELEITWORT / INHALT 



Dieses Jahr war ein entmutigendes Jahr. Biometrie 
ist in die Reisepässe gekommen, das Urheberrecht 
wurde verschärft, das Bankgeheimnis ist uns durch 
die Finger geglitten und die gute alte Briefmarke 
ist quasi abgeschafft. 

Ja, richtig! Abgeschafft. Ausgetauscht gegen einen 
herzlosen, volldigitalen 2D-Barcode. Unlesbar für 
uns Menschen und jeder Ästhetik beraubt. Und bei 
dem Versuch "darf ich dir mal meine Briefmarken- 
sammlung zeigen..?" wird es in Zukunft skeptische 
Blicke geben. 

Nachdem wir in den letzten Wochen mit einer 
ungewöhnlichen Fülle von anonym zugesand- 
ten und oftmals hochspannenden Dokumenten 
bedacht wurden, möchte die Redaktion die Gele- 
genheit benutzen allen Einsendern auf diesem 
Wege zu danken. Wir mussten uns in dieser Aus- 
gabe aus Platzgründen auf den Hack-a-Bike Report 
und die nähere Betrachtung des Gesundheitskar- 
ten-Backends beschränken, aber werden die ande- 
ren uns zugespielten Leckerbissen auf jeden Fall in 
der nächsten Ausgabe vorstellen. 

Für den Fall das dem einen oder anderen Leser 
Papierstücke oder Bits in die Hände fallen die im 
öffentlichen Interesse der Publikation in der Daten- 
schleuder bedürfen, bitten wir um Zusendung per 
Post (bitte den bewährten unmarkierten brau- 
nen Umschlag für anonym zugespielte Dokumen- 
te verwenden) oder e-mail (an ds@ccc.de, bei 
hohem Risikofaktor wird ein Anonymizer sowie die 
geschickte Nutzung eines öffentlichen Netzes emp- 
fohlen). 



Entmutigende Tendenzen hin oder her: sie unter- 
streichen nur die Dringlichkeit, uns zu organisie- 
ren und tätig zu werden. Vor diesem Hintergrund 
betrachtet, lehnen wir uns bestimmt nicht zu sehr 
aus dem sprichwörtlichen Fenster, wenn wir Euch 
einen heissen diesjährigen Congress versprechen. 

Die Datenschleuder-Redaktion 



PS. Einige von Euch werden es vielleicht bemerkt 
haben: ohne grosse Ankündigung (Neudeutsch: 
Launch) hat die Datenschleuder mittlerweile nach 
und nach eine Online-Heimat gefunden. Unter 
http : //ds . ccc . de können nun Artikel der (meis- 
ten) vergangenen Ausgaben, sowie die Titelge- 
schichte der aktuellen Ausgabe nachgelesen wer- 
den und finden so Ihre suchmaschinenerfassbare 
Heimat. 
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Ein HackABike in freier Wildbahn - der Ausschnitt zeigt den im Artikel besprochenen Kasten. 
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Der Redaktion Datenschleuder wurde eine Technologieanalyse anonym zugespielt, die unten 
stehend zu Bildungszwecken dokumentiert ist. Der Text wurde redaktionell gekürzt. 



.ll 5;:: :!j- .:ll= : i|j III! jjllil::. .^"ij! .jjl:!!jj: :ll : .llrlij:. :!{:!!!" 

von anonymous, Leserbriefe bitte an <ds@ccc.de> 

Schon immer mal nachts ohne Transportmöglichkeit in einem fremden Bezirk auf- 
gewacht? "Mal schnell" ein Fahrrad benötigt? In Berlin und anderen Großstädten 
Deutschlands bietet Die Bahn mit dem Call-A-Bike Service Abhilfe. 



Im November 2003 wurde uns ein Call- 
ABike 'zugetragen', das nicht richtig 
abgeschlossen wurde. Dieses muss- 
te erstmal als Testobjekt herhalten. Die 
meisten dachten, dass in dem Schloss- 
kasten GPS oder sonstiger Funk enthal- 
ten sei, nach dem Öffnen war hiervon 
jedoch nix zu sehen. Um die Schrauben 
der Schlosskästen zu öffnen, benötigt 
man nur ein Torx TR (Temper Resistant). 
In dem Kasten ohne Display ist die 
Stromversorgung durch Batterien sicher- 
gestellt (3x 1.5V Mono). 

Die beiden Kästen sind durch eine Art 
Bügel miteinander verbunden. In die- 
sem Bügel befindet sich ein sechspoli- 
ges Kabel für den Strom und zwei Spu- 
len. Damit kann geprüft werden, ob das 
Schloss wirklich geschlossen ist, oder 
einfach kein oder nur irgendein ande- 
rer Bolzen zum Verschließen genom- 
men wurde. 



Der Kasten mit dem Display enthält den 
Exzentermotor zum Öffnen des Schlos- 
ses, zwei Taster (Mikroschalter) und ein 
kapazitives 5x2-Touchpad. Die Haupt- 
logik sitzt unter dem Display. Sie ist 
nochmal durch eine Metallplatte abgesichert, wel- 
che nur die Kabel zum Display/Touchpad durchlässt. 
Damit wird der Motor und der 
Verschlussmechanismus vor 
einer Attacke durchs Display 
geschützt. 

Die gesamte Platine ist mit 
schwarzem Silikon Übergossen, 
das man erstmal runterkrat- 
zen muss. Das geht prima mit 
einer Mess-Spitze. Außer einer 
streichholzschachtelgroßen Pla- 
tine (Rückseite Datenschleu- 
der 82), auf der ein Atmel 
AT90S8535 (8-Bit-Risc-Prozes- 
sor, 4x8-IO-Pins, 8KB Flash, 
512-Bytes-EEProm und 512- 



Kurzeinführung in das CallABike System 

Als Kunde ruft man die CallABike-Zentrale und gibt per DTMF-Wahl die 
vierstellige Radnummer durch. Von der Zentrale erhält man dann den 
vierstelligen Code, mit dem man das CallAßike-Fahrad öffnen kann. Zur 
Sicherheit wird man nach dem Anruf von der Zentrale zurückgerufen. Die 
letzten vier Ziffern des Rückrufes enthalten nochmal den Code - annehmen 
muss man den Anruf deswegen nicht. Jetzt läuft die Uhr und der Kunde 
muss pro Minute 6 Cent bezahlen (mit Bahncard nur 4 Cent). Wenn der 
Kunde das CallABike einfach mal schnell abstellen will (z.B. für einen 
kurzen Einkauf), kann man das CallABike abschließen und im Display auf 
'Nicht Abgeben' tippen. Es ist sozusagen kurz geparkt. Danach kann man 
das CallABike mit dem gleichen Code wie beim ersten Mal öffnen. Das kann 
man so oft wiederholen, wie man möchte. Die Zeit, die man bezahlen muss, 
läuft natürlich weiter. 

Wenn der Kunde das CallABike dann endgültig abgeben will, muss er 
beim Schließen auf 'Abgeben' tippen; das CallABike gibt einem dann 
den Rückgabecode. Mit diesem Code kann man gegenüber der Zentrale 
'beweisen', dass man das CallABike wirklich wieder abgeschlossen hat. Man 
ruft jetzt einfach wieder die Zentrale an und gibt den Rückgabecode durch. 
Danach muss man noch die Straßenecke auf Band sprechen, an der man 
das CallABike abgestellt hat. Die Mietzeit wird damit dann auch beendet. 

Es ist auch möglich, zwei Räder mit einem Anruf auszuleihen oder 
abzugeben. Wenn der Kunde in seiner Nähe kein CallABike-Rad findet, 
kann er auch die Zentrale anrufen und fragen, wo das nächste CallABike- 
Rad steht. Ein Servicemitarbeiter der Bahn schaut dann in der Datenbank 
nach und gibt den Standort des nächstgelegenen CallABike-Rads durch. 




Bytes-RAM) [1], ein paar LEDs (rot, grün und IR) und 
IR-Receiver aufgebracht sind, enthält der Kasten noch 
ein paar andere elektrische Bau- 
teile (Motor, Schalter und ein Bee- 
per). Es ist auch ein Neigungssen- 
sor vorhanden, aber im Code wird 
er nicht benutzt. Daher bestand 
keine Gefahr, uns zu orten. 

Es wurden ein paar Bilder von der 
Aktion gemacht, aber dann lag 
die Technik erstmal zwei Mona- 
te einsam in einer Kiste, weil wir 
es nicht geschafft haben, das 
CallABike zu booten. Es dauer- 
te eine Weile, bis wir merkten, 
dass das System nach dem Boo- 
ten durch ein Infrarot-Signal akti- 
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viert werden muss. Das war mehr oder weniger Zufall. 
Wenn man eine normale Glühlampe benutzt, um bes- 
ser sehen zu koennen, piepte die Elektronik gelegent- 
lich scheinbar unmotiviert. Wie sich später herausstell- 
te, reichte der durch die Glühlampe emittierte IR-Anteil 
aus, um den IR-Receiver zu triggern und den Bootvor- 
gang fortzusetzen. Beim Booten testet sich das System 
selbst, und der Empfang eines Infrarot Signals gehört 
eben dazu. Im Zuge fortschreitender Professionalisie- 
rung™ wurde in der Folgezeit die Glühlampe durch ein 
Infrarot-Photon-Micro-Light ersetzt. 

Bei unserer weiteren Analyse des Systems begannen 
wir damit, alle Anschlüsse des Atmel durchzumessen, 
um uns einen ungefähren Schaltplan zu erstellen (siehe 
Bild). Die Datenblätter für den Atmel und das verwen- 
dete Display haben wir uns aus dem Web besorgt. 

Im Januar hatte einer der Beteiligten dann endlich eine 
Idee, wie weiter vorzugehen sei. Auf der Platine war 
uns eine unbenutzte 6-polige Steckerleiste aufgefal- 
len, und wie sich herausstellte, handelt es sich dabei 
um den ISP-Connector (In System Programming) des 
Atmel. Daran schlössen wir dann ein Atmel-Develo- 
per-Board (STK500) an. Zum Auslesen wurde haupt- 
sächlich das freie UISP ("Uisp is a tool for AVR mic- 
rocontrollers which can interface to many hardware 
in-system programmers" [2] ) benutzt. Die auf dem 
Atmel vorhandenen „lntellectual-Property"-Bits waren 
in einem Undefinierten Zustand, deswegen konnten 




EEPROM Inhalt: 




0X0000 


- 0X0001 


unused 


0x0002 




lock_sensor_calibration 


0x0003 


- 0X0019 


unused 


0X001A 


- 0X001B 


16bit counter (scrambler) 


0X001C 




unused 


0X001D 


- 0X001F 


CallABike Radnummer 


0x0020 


- 0X009F 


128 Byte Random (Key) 


0X00A0 


- 0X00A2 


Die ersten drei Bytes des Key nocheinmal 


0X00A3 


- 0X00AF 


unused 


0X00B0 


- 0X01FF 


Text für Display 



... Es gibt natürlich auch andere Zeitgenossen, 
die haben, schon aus sportiven Gründen, allerlei 
versucht, um die Standfestigkeit der Hardware oder 
das elektronische Prinzip der eingebauten Mikrochips 
und Prozessoren zu ergründen. 

Sie rückten dem Schloss mit Schraubenziehern und 
gängigen Imbusschlüsseln zu Leibe. 

Sie versuchten ihr Glück mit Brechstange, 
Vorschlaghammer, sogar mit der Motorflex. Oder, 
ganz Smart, mit Laptop, mit Dechiffrierprogrammen, 
auch mit Fangfragen an das Wartungspersonal. 
Doch vergebens! Wieder lächelt Reth, der einst erste 
Ausflüge auf einem grünen Puky-Rad unternahm, 
sich heutzutage aber als "postmoderner Urbaniker", 
denn als "Fahrradfreak" versteht. Er lächelt und sagt: 
"Erst diese Technik macht uns zum weltweit einzigen 
stationsunabhängigen Stadtradsystem. Der Code ist 
nicht zu knacken und darauf sind wir richtig stolz." 

... aus dem Kundenmagazin DB mobil 



wir das Flash des Atmels mit der 8KB großen Firmware 
auslesen. 

In den nächsten Wochen waren mehrere Hacker damit 
beschäftigt, den ausgelesenen Assemblercode zu ver- 
stehen und zu dokumentieren. Dazu verwendeten wir 
AVR-Studio [3] und Ida Pro [4]. Den Scramble Code 
(zum berechnen der Ausleih- und Abgabecodes) fan- 
den wir relativ schnell, da sich dort eine Menge rotate- 
und-shift-Befehle befanden. Den Initialisierungscode 
erkannten wir wieder, da wir wussten, dass der Motor 
sich beim Einschalten zweimal herumdreht. So konnten 
wir das gelernte immer wieder an unserem Prototyp 
auf Richtigkeit überprüfen. 

Die Ausleih- und Abgabecodes werden durch einen 
Scrambler generiert, der mit einem 16Bit-Counter des 
CallABikes und einem Zustandswert aufgerufen wird. 
Ein gerader Counterwert erzeugt Ausleihcodes und 
ein ungerader erzeugt die Abgabecodes. Der Scramb- 
ler nutzt den Counter und das Zustandsbyte, um ein 
Offset auf ein 1024 Bit großes Feld zu errechnen. Die- 
ses Feld ist ein für jedes CallABike eindeutiger binä- 
rer String, der als der (wahrscheinlich) eindeutige Key 
des CallABikes bezeichnet werden könnte. Von die- 
sem Offset aus werden dann 4x4 Bit genutzt, die die 
vier Ziffern für die Ausleih- und Abgabecodes reprä- 
sentieren. Die 16 Bit des Counters werden aber 
schlecht genutzt, denn schon nach 1024 Ite- 
rationen wiederholen sich die Ausleih- und 
Abgabecodes. Das bedeutet auch, dass es nur 
512 Ausleihcodes je CallABike gibt, da es nur 
512 gerade Offsets gibt die auf den Key (1024 
Bit) zeigen können. CallABikes, die wir geöff- 
net haben und die wir wegen der Lockbits 
nicht auslesen konnten, haben wir mit einem 
Script 51 1 mal resetten lassen (bei einem Reset 
erhöht sich der Counter immer um zwei). 
Damit haben wir den ursprünglichen Zustand 
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wiederhergestellt, und das CallABike war wieder 'in 
sync' mit der Zentrale. 

Wer sich das Display mal genauer angeschaut hat, wird 
festgestellt haben, dass der Zeichensatz ein proportio- 
naler ist. Dazu gibt es im Code eine Tabelle, in der die 
Länge des Zeichens und die Position im Flash gespei- 
chert sind. Ein V und ein '!' belegen nur ein Byte, 
wogegen z.B. ein 'w' sieben Bytes belegt. Die großen 
Logos und das Zahleneingabefeld liegen als 400 Byte 
große Bitmaps vor. Die lange schwarze Linie im Call- 
ABike-Logo zeigt die Stärke der Spule im Schloss an. 
Das haben wir nur durch das Code-Auditing heraus- 
gefunden. 

Unser erstes Ziel war es, den aus unserem Disassem- 
bler erhaltenen Sourcecode so anzupassen, dass nach 
dem Assemblieren mit dem Commandline Tool Avra 
("Assembler for the Atmel AVR microcontrollers" [5] 
) ein EXAKT identisches Binary herauskam. Auf der 
Grundlage dieses Referenzcodes konnten wir dann 
endlich Änderungen vornehmen. 

Nachdem wir uns diese Grundlage geschaffen hatten, 
konnten wir das CallABike mit unserem eigenen Code 
flashen. 

Da wir keine Vulnerabilities oder Backdoors fan- 
den (jedes CallABike hat einen eigenen Key, der im 
EEPROM gespeichert ist), mit denen man ein CallABi- 
ke exploiten könnte, ohne es aufzuschrauben, kamen 
wir auf die Idee, uns eine eigene Backdoor in den Code 
zu programmieren. Hört sich eigentlich ganz leicht an, 
ist es aber nicht. Erstmal mussten wir den Code der 
BAHN optimieren, um uns den entsprechenden Platz 
zu schaffen. Schließlich sollte ja auch noch ein Logo 
mit 400 Bytes von uns in das 8KB große Flash. Den 
Datenmüll, den man über unserem HackABike Logo 
sehen kann, ist der Backdoor Code. Das sparte noch- 
mal ca. 150 Bytes. Außerdem wollten wir nicht, dass 
man mit dem Backdoor Code normalen Kunden, die 
das Rad nur geparkt (verschlossen, aber nicht abgege- 
ben) haben, das ausgeliehene HackABike wegschnap- 
pen konnte. Das erforderte noch ein paar Zeilen mehr 
im Code. Auch kann man mit unserem Backdoor Code 
das HackABike nicht 'parken', da ja der Öffner nichts 



bezahlen muss und 
deswegen nicht 
motiviert ist, sich 
weiter um das Rad 
zu kümmern, und 
es aber auch nie- 
mand anders auf- 
machen könnte. 
Um das HackABi- 
ke auch auf grö- 
ßere Entfernung 
noch von sei- 
nen unbehandel- 
ten Verwandten 
unterscheiden zu 
können, haben wir 
ihm eine leicht ver- 
änderte Blink-Sequenz 
beigebracht. 



Code zum Ceneriezen dez Abgabe/Ausleihcodes 
bei gegebenem Key aus dem eepzom 

unsigned char g_key[4] ; 

void scrambler(uchar param, long counter) { 
long bitoffset; 
uchar r21 = param, rZ8 = 1; 
Short r27_26 = counter, Short r3i_30; 
r28 «- r27_26 & 7; 



r27_26 
r27_26 
r3i_30 
r27_26 
r27_26 
r27_26 
r27_26 
r27_26 
bitoffset 
r27_26 »■ 
r27_26 +» 
r27_26 &- 



r21; 
0x3ff; 
r27_26; 
- 5; 
r3i_30; 
0x3ff ; 
r28; 
0x3ff; 
= r27_26 ( 
i 3; 
0x20; 
0xff ; 



fillkey(r27_26, bitoffset); 



} 

void fillkey(long address, long bitoffset) { 
uchar rl6; 
long fullkey; 

fullkey = eeprom[address++] « 16; 
fullkey += eeprom[address++] « 8; 
fullkey += eeprom[address++] ; 
fullkey »= bitoffset; 
rl6 - fullkey 8. 0xf ; 

if(rl6 >» 10) rl6 — 10; 
g_key[3] = rl6; 
rl6 = (fullkey »4)8. 0xf ; 
if(rl6 >» 10) rl6 — 6; 
g_key[2] = rl6; 
rl6 - (fullkey »8)8. 0xf ; 



} 



ifCrl6 >» 10) rl6 
g_key[l] = rl6; 
rl6 = (fullkey » 
ifCrlö >» 10) rl6 
g_key[0] - rl6; 



Im Verlauf der weite- 
ren Analyse des Codes 
ist uns aufgefallen, 
dass das CallABike 
im Abgabecode inte- 
griert Statusinforma- 
tionen an die Zentra- 
le durchgeben kann. 
Je nachdem, in wel- 
chem technischen 
Zustand sich das Call- 
ABike befindet, kann 
es unterschiedliche 
Rückgabecodes - 
abhängig vom bereits 
erwähnten Zustands- 
byte - angeben. Das CallABike kann z.B. melden, dass 
die Batterie nicht mehr lange hält, oder der Motor 
für das Schloss nicht mehr in der richtigen Stellung 
ist. Wenn man z.B. den Schließknopf sie- 
ben mal ohne eingeführten Bolzen drückt, 
liefert der Scrambler einen entsprechen- 
den Rückgabecode, der gültig ist, diesen 
Zustand aber für die Zentrale erkennbar 
anzeigt. Von diesen Codes gibt es 52 (eine 
Matrix aus 4x13). 

Die Backdoor erlaubt, das HackABike 
mit einem von uns festgelegten Ausleih- 
code einfach zu öffnen. Wenn man das 
HackABike dann wieder abgibt, ist es ganz 
normal wieder ausleihbar. Es steht auch 
wieder der Ausleihcode des vorherigen 
Kunden im Display. Die Zentrale merkt von 
diesem eingeschobenen Ausleihvorgang 
nichts - außer, dass es an einem anderem 
Ort steht, als es in der Datenbank vermerkt 
ist. Wenn es dann aber wieder normal aus- 
geliehen und abgestellt wird, ist auch in der 
Zentrale alles wieder in Ordnung. 



10; 



12) 8. 0xf ; 

— 6; 
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Fürs CallAEike mit der Nummer 2883 z.B.: 

unsigned char eeprom[ ] = { 

0x5A , 0xD5 , OxAD , 0x6E , 0xFD , 0xD7 , 0x34 , 0x78 , 
0xB3 , 0x03 , 0x22 , 0x13 , 0x61 , 0x23 , 0xAD , 0xFE , 



0x51 , 0x6E , 0xAA , 0xA2 , 0xD4 , 0xB7 , 0xBA , 0xC0 
0x78 , 0x9A, 0x84 , 0x55 , 0x2A , 0xB9 , 0x6E , 0xBC , 
0x33 , 0x15 , 0x2C , 0x97 , 0x33 , 0x98 , 0x4B , 0x78 , 
0x43 , 0xE5 , 0x20 , 0xD5 , 0xlC , 0xlC , 0x75 , 0x12 , 
0x2A , 0x91 , 0x17 , 0xFC , 0X0C , 0x61 , 0x31 , 0x31 , 
0x50 , 0x6D , 0xFD , 0x5C , 0xC5 , 0x60 , 0x8D , 0xE0 , 
0X0A , 0xF2 , 0x85 , 0xFl , 0x3B , 0xA3 , 0xBD , 0x74, 
0xF3 , 0xD4, 0x9E , 0xBB , 0x45 , 0x95 , 0x69 , 0x24, 
0x79 , 0x36 , 0x9A , 0xA6 , 0x66 , 0x96 , 0xFB , 0xE8 , 
0x5D , 0x38 , 0x34 , 0x28 , 0xC0 , 0x51 , 0x3B , 0x18 , 
0x46 , 0xCA, 0xD9 , 0xE3 , 0xD7 , 0xC8 , 0x86 , 0x01 , 
0x11 , 0x60 , 0xF2 , 0xF0 , 0xA4 , 0xA4, 0xEF , 0x16 , 
0x3E , 0xBE , 0xB9 , 0xlF , 0xA8 , 0xF9 , 0x61 , 0X0B , 
0xD6 , 0x7F , 0x75 , 0xE7 , 0xF4 , 0x31 , 0x3F , 0x6B 

}; 



Um ein CallABike 
in ein HackABike zu 
verwandeln, muss- 
ten wir sechs Schrau- 
ben auf der Innensei- 
te des Schlosskastens 
mit dem Display öff- 
nen und das Kabel 
des STK500 an den 
ISP-Anschluss der 
Platine stecken. 
Danach haben wir 
ein Script gestartet, 
dass das Flash und den 
EEPROM Bereich aus- 
liest. Das EEPROM wird danach mit zurückgesetztem 
Counter und dem Flash mit unserer Backdoor wieder 
zurückgeschrieben. Damit niemand unsere Backdoor 
auslesen kann, haben wir natürlich noch die Lockbits 
gesetzt. Ein geschulter Hacker brauchte ca. 12 Minu- 
ten, um zwei CallABikes parallel in HackABikes zu ver- 
wandeln. 

Da UISP das Setzen der Lockbits nicht korrekt unter- 
stützte, mussten wir das erstmal einbauen. Dazu haben 
wir den Output von AVR-Studio 
mit einem serial sniffer mitgelesen 
und uns die entsprechenden Korn 
mandos für das STK500 rausge- 
sucht und in UISP eingebaut. 



Die UART-Loop erlaubt folgende Kommandos: 

0x5B Fahrradnumtner auslesen 

0xCE Spule Kalibrieren 

0xC5 RAM ab 0X00AD lesen 

Nach Eingabe der Ersten 32 Randombytes (Key): 

0xCA Watchdog enablen (rebooten) 

0xC8 Randombereich im EEPROM schreiben und wieder lesen 
0xCD Andere Bereich im EEPROM schreiben und wieder lesen 



der benötigt wird, um die Abgabe- und Ausleihcodes 
berechnen zu können. Dazu muss vermutlich das Call- 
ABike geöffnet und ausgelesen werden. Es wurde nur 
versäumt, die Lockbits zu setzen, um die Firmware vor 
dem Auslesen zu schützen. Unsere Attacke ist von den 
verbrauchten Mannstunden wohl mehr Wert als ein 
paar Dutzend CallABikes. 

[1] http://www.atmel.com/dyn/resources/prod_documents/ 
1041S.PDF 

[2] http://savannah.nongnu.org/projects/uisp/ 

[3] http://www.atmel.com/dyn/products/ 

toots_card.asp?tool_id=2725 

[4] http://www.datarescue.com/ 

[5] http://avra.sourceforge.net/ 



Auszug aus dem eeprom des CallABike 2882, pro Counter jeweils 3 Ausleihcodes 
gefolgt von den 52 möglichen Abgabecodes 

Counter 0X01E4: 3053 2671 1775 



/usr/local/bin/uisp -dserial=\ 
/dev/ttyU0 -dprog-stk500 \ 
-dpart=AT90S8535 --erase --upload \ 
— verify if=flash_backdoor.hex 

Abschließend ist festzustellen, dass 
das technische Design des Call- 
ABike in unseren Augen sehr gut 
ist. Jedes CallABike hat vermut- 
lich einen eigenen 1024 Bit Key, 






-00- 


-01- 


-02- 


-03- 


-04- 


-05- 


-06- 


-07- 


-08- 


-09- 


-10- 


-11- 


-12- 


-13- 


00 


8234 


7161 


4355 


4892 


9290 


9998 


8304 


7365 


9562 


2095 


3043 


6551 


7590 


7270 


01 


8589 


6501 


7447 


1493 


6180 


3012 


1741 


8518 


9843 


8709 


9172 


1151 


9723 


9368 


10 


9544 


7869 


5662 


4655 


8255 


2595 


9391 


6608 


8674 


3599 


4120 


6087 


5181 


8181 


11 


3273 


7512 


6017 


4884 


8282 


9760 


7439 


2556 


6031 


9146 


0413 


3699 


9160 


2446 


Counter 0X01E6: 7145 5444 7084 




















-00- 


-01- 


-02- 


-03- 


-04- 


-05- 


-06- 


-07- 


-08- 


-09- 


-10- 


-11- 


-12- 


-13- 


00 


1382 


8104 


4463 


7399 


2412 


4608 


5856 


1205 


4872 


7241 


7327 


7391 


8241 


5088 


01 


9445 


6228 


3243 


9514 


7081 


1365 


0360 


6858 


1434 


3263 


7921 


5394 


7103 


9678 


10 


5372 


3104 


5861 


9271 


8793 


4825 


4210 


7162 


2400 


9084 


4227 


4645 


5182 


7942 


11 


0325 


2894 


4580 


7946 


3428 


8162 


2675 


0674 


7051 


2872 


6088 


5256 


4789 


9610 



Hier sieht man das CallABike 2882 mit dem Counterstand 0X01E4. Ein Kunde 
erhält als Öffnungscode die 3053. Wenn das CallABike normal abgegeben wird 
und alles in Ordnung ist, bekommt er als Abgabecode die 8234. Falls z.B. die 
Batterie schwach ist (-01-) bekommt er als Code die 7161. 



-01- 
-02- 

-03 



-06- 
-07- 
-08 
-09- 
-10- 
-11- 

-12 

-13- 



0-5 (x-Dimension) dezimal: 
Alles OK 

ßatteriespannung niedrig 

Schloss ist nicht richtig zu (Spule) 

gelb-blaues Kabel defekt 

(Spule im Bolzen) 

grün-graues Kabel defekt (Spule im 
Schlosskasten) 

Motor ist nicht in richtiger Position / 

Knopf nicht gedrückt 

Motor ist nicht komplett herum 

Knopf nicht gedrückt 

Rückgabe default (unklar) 

unklar 

mind. drei misslungene Abgabeversuche 

sieben misslungene Abgabeversuche. 

Schloss ist nicht zu! 

unklar 

unklar 



Bit 6-7 (y-Dimension) binär 
-00- Alles OK 

-01- ßatteriewechsel nötig 
-10- unklar 
-11- unklar 



dip ddtpr.5[hLpudPf 



#85 / 2004 



5 



I WANT TO RIDE YOUR BICYCLE 




O 1 Motor Schlossfreigabe 



#85 / 2004 



dip dalenschlpudpf 
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Das Gesundheitskarten 
Backend 

von Verband forschender Patienten im CCC <ds@ccc.de> 



IT-Projekte der öffentlichen Hand kommen nur zu 10% zum erfolgreichen Abschluß. 
Aber selbst wenn sie abgeschlossen werden, wie es bei der Cesundheitskarte im 
Moment aussieht, kann die eigentliche Katastrophe noch ausstehen. 



Vorwort 

Die Planungen zur Gesundheitskarte sehen vor, die 
Patientendaten zentral zu speichern und Ärzten über 
ein Datennetz zugänglich zu machen. Auch soll die 
Cesundheitskarte des Patienten die Rezepte speichern. 
Der Patient geht damit zur Apotheke, es gibt keine 
Notwendigkeit für Zettel mit unleserlichen Verschrei- 
bungen und leicht fälschbaren Unterschriften mehr. 

An sich kein Problem, aber Patientendaten (das bein- 
haltet neben den üblichen personenbezogenen Daten 
die Krankengeschichte des Patienten, wogegen er 
womit behandelt wurde, wogegen er allergisch ist, 
etc.) sind sozusagen der Inbegriff der vom Datenschutz 
gemeinten schutzbedürftigen Daten. Daher kommen 
hier diverse Bedrohungsszenarien ins Spiel: 

• Wenn jemand ins zentrale Rechenzentrum einbricht, 
darf er die Daten nicht lesen können 

• Wenn jemand beim Arzt einbricht, darf er die Daten 
von dessen Patienten nicht lesen können 

• Darf der Apotheker Zugriff auf die Krankengeschich- 
te des Patienten haben? 

• Vielleicht will man noch, daß der Gynäkologe kei- 
nen Zugriff auf Daten von Männern hat? Oder daß 
der HNO-Arzt nicht zu sehen kriegt, ob der Patient an 
Geschlechtskrankheiten leidet? 



Implementation 

Als Fundament der Infrastruktur hinter der Gesund- 
heitskarte ist das PaDok-Konzept der Fraunhofer- 
Gesellschaft gewählt worden, an dem diese seit 1993 
arbeiten. Der gute Name der Fraunhofer-Gesellschaft 
gekoppelt mit der langen Projektlaufzeit deuten auf 
eine besonders saubere Planung gekoppelt mit makel- 
loser Umsetzung durch international namhafte Exper- 
ten und Tests durch unabhängige Audit-Institute hin. 




Beim Blick in die 
PaDok-FAQ [1] kom- 
men uns allerdings ers- 
te Zweifel: 

Q: Inwieweit enthält 
die Lösung proprietäre 
bzw. offene / standar- 
disierte Komponenten? 

A: D2D I PaDok setzt durchgängig auf standardisierte 
Formate und Schnittstellen. Einzige Ausnahme hiervon 
ist das eigentliche Transport- Protokoll zwischen dem 
(als datentechnisch "unsicher" einzustufenden) Kom- 
munikations-Client und dem jeweils zugeordneten 
Server. Hier wird ein spezielles und hoch-ritualisiertes 
RPC-Protokoll verwendet, dass sich jedem Zugangs- 
Versuch mit Hilfe allgemeingültiger Internet-Werkzeu- 
ge verschließt. 

Ein "hoch-ritualisiertes RPC-Protokoll" klingt dann 
doch eher nach Quacksalberei als nach Expertentum. 
Aber gut, das kann ja ein Übersetzungs- oder Doku- 
mentationsfehler sein. Weiter unten in dem Dokument 
erfahren wir, daß die PaDok-Software auf einem exis- 
tierenden Windows-Rechner im lokalen Netz der teil- 
nehmenden Praxis laufen soll. Einzige Anforderungen: 
hat ISDN und kann auf einen File-Server schreiben, wo 
die Dokumente dann hin sollen. Bei den Worten "exis- 
tierender PC" stellt sich aber die Frage, ob das tatsäch- 
lich ein separater Rechner sein wird oder die Software 
einfach mit auf den PC der Praxis-Buchhaltung instal- 
liert wird. 

Das PaDok-Konzept ist der Backend-Teil der Cesund- 
heitskarte, d.h. zwischen Arzt und zentraler Datenhal- 
tung. Zur Sicherheit der Cesundheitskarte selbst (die 
der Patient dann in den Händen hält) können wir bis- 
lang noch nichts sagen. Trotzdem ergeben sich interes- 
sante Fragestellungen. Z.B. stellt sich die Frage, ob sich 
ein Abhängiger über einen Trojaner auf dem PC des 
Arztes E-Rezepte ausstellen kann. 
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Wir wollten es genauer wissen und haben uns auf der 
CeBIT bis zum PaDok-Stand durchgeschlagen, uns 
umfassend beraten lassen, und Unterlagen mitgenom- 
men. Die Unterlagen sinn voll Buzzword-kompatibel 
und sprechen von signaturgesetzkonformen digitalen 
Signaturen, starker Verschlüsselung und Einhaltung Pri- 
vatsphäre. 

Um so schockierender war, was uns dann von einem 
Fraunhofer-Mitarbeiter bei einem Bierchen von einer 
Teststellung erzählt wurde, die er mal kurz gesehen 
hatte: 

1. Das Kartenterminal hatte keine PIN-Eingabe. Die 
PIN gibt man auf dem PC ein. Ein Trojaner kann das 
also abfangen. 

2. Der Kartenleser wird einfach seri 
angeschlossen. Mit Windows- 
Hausmitteln kann ein Trojaner 
die Kommunikation abfan- 
gen, mitlesen und sogar 
manipulieren. 

3. Aus Kostengrün- 
den findet die 
Kryptographie 
nicht auf den Kar- 
ten statt, sondern 
im PC. Die Karte ist lediglich 
ein Lagerraum für den geheimen 
Schlüssel, den die Karte mit der (mitge 
lesenen) PIN rausrückt. 

Wenn also ein Angreifer einen Trojaner auf dem Arzt- 
rechner installiert, kann er den geheimen Schlüssel des 
Arztes extrahieren, sich ins Internet einwählen (der 
Arztrechner hat ISDN-Zugang für das PaDok-System, 
darüber kann der Trojaner sich also prima irgendwo 
einwählen), und den Schlüssel irgendwo ablegen. In 
den Unterlagen wird vorgeschlagen, daß die Ärzte sich 
nur über einen ISDN-Router und nicht über ISDN-Kar- 
te einwählen sollen. Man darf sich aber keiner Illusion 
hingeben, daß das tatsächlich hilft. Falls der Trojaner 
nicht nach Hause telefonieren kann bricht der Angrei- 
fer eben nachts ein und holt sich den Schlüssel von der 
Festplatte. 

Diese Aufbewahrung des Schlüssels ist ein kapitaler 
Designfehler. Insbesondere stellt sich das ganze Kar- 
tenleser- und PIN-Brimborium als lächerliche Sicher- 
heitssimulation ohne Steigerung der tatsächlichen 
Sicherheit heraus, wenn man sich diese Möglichkeiten 
vor Augen führt. 

Die E-Rezepte liegen nicht komplett auf der Gesund- 
heitskarte des Patienten, sondern auf dem D2D-Server, 
und auf der Karte liegt lediglich ein Freischaltcode. Mit 
diesem holt sich der Apotheker dann das Rezept vom 
Server und entschlüsselt es. So ist immerhin verhindert, 
daß sich ein Angreifer ohne weiteren Zugriff auf einen 
kompromittierten Arzt-PC E-Rezepte ausstellen kann. 
Aber über den Trojaner auf dem Arzt-PC Dokumen- 



te auf dem zentralen Server abzulegen erscheint nicht 
wirklich schwierig, zumal der Angreifer ja den Schlüs- 
sel des Arztes hat. 

Eine weitere Frage ist, in welcher Form die Dokumen- 
te eigentlich verteilt werden. Die Internet-Dokumen- 
te, die wir gesehen haben, schlagen XML vor, aber das 
scheint nicht das einzige Format zu sein. Auf Nach- 
frage meinte unser Kontaktmann, daß man da auch 
Word-Dokumente (und damit Makroviren) transpor- 
tieren kann. Ein Angreifer kann so also Arztpraxen 
angreifen, indem er mit Makroviren infizierte Doku- 
mente zu seinen Patientendaten tut, z.B. indem er 
sie bei einem anderen Arzt abgibt als seine Fallhisto- 
rie "von einem anderen Arzt" auf Diskette, und der sie 
dann ins PaDok-System einpflegt. 

Ein interessantes Detail ist, 
daß die Dokumen- 
te nur beim 




Transport verschlüsselt sind. Über den 
Microsoft-Plattformen inhärenten Makrovirenangriff 
kommt man so auch an Daten anderer Patienten her- 
an, die noch auf dem System des angegriffenen Arz- 
tes herumliegen. Und da können vielleicht auch noch 
sensible Patientendaten liegen, die gar nicht im PaDok- 
System eingepflegt wurden. 

Eskalation 

Nachdem klar ist, daß das System auf Arztseite kom- 
promittierbar ist, stellt sich natürlich die Frage, wieviel 
ein Angreifer von einem übernommenen Arztsystem 
aus an der zentralen Infrastruktur machen kann. Der 
erste Teil dieser Fragestellung ist, wie weit ein Angrei- 
fer mit einem ausgespähten geheimen Arztschlüssel 
kommt. 

Laut http://www.kvno.de/importiert/habu_300.pdf authen- 
tisiert sich der Arzt-PC bei der Zentrale über seine 
ISDN-Rufnummer. Die Zentrale ruft dann zurück. Auch 
hier ist möglicherweise ein Angriff auf die umliegende 
Infrastruktur möglich, über umprogrammierte ISDN- 
Anlagen oder man würde eben über den Trojaner den 
Arzt-PC fernsteuern. 

Die zentrale Innovation bei PaDok ist, daß man Doku- 
mente "ungerichtet verschlüsselt". Die Fraunhofer- 
Gesellschaft läßt kaum eine Gelegenheit aus, auf dieses 
"hochwertige" Softwarepatent hinzuweisen. Die Idee 
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ist, daß die Dokumente auf dem Server liegen, aber 
der Dateiname aus der (geheimen) Vorgangskennung 
besteht. Wenn der Patient jetzt zu einer neuen Praxis 
geht, hat er von der alten einen Schrieb mit der Vor- 
gangskennung dabei, gibt diese der neuen Praxis, und 
die kann dann diese Datei abrufen. 

Das klingt ja erst mal wie eine gute Idee, bis man mal 
genauer hinschaut, wie sich so eine Vorgangskennung 
zusammensetzt. Der Dateiname besteht aus der Vor- 
gangs-ID und einem "Krypto-Teil". Die Vorgangs-ID 
ist einfach "aa", die Arzt-ID (die man von früheren 
Überweisungen von/zu dem Arzt her kennt), ein fort- 
laufender Vorgangszähler, das Datum der Akte sowie 
ein Ordnerzähler (einzelner Buchstabe, beginnend mit 
"a"). Das ist alles trivial ratbar. 

Diese Vorgangs-ID ist auf dem Server der Name eines 
Verzeichnisses. In dem Verzeichnis liegen die eigentli- 
chen Dateien, und zwar mit dem Zeitstempel des Cli- 
ents beim Anlegen des Dokumentes in Millisekunden. 

Die Vorgangskennung besteht nun aus der Vorgangs- 
ID und dem "Krypto-Teil". Insgesamt hat man 21 
Zeichen Platz, von denen die Vorgangs-ID nun lei- 
der schon 16 belegt. Das hinterläßt bei der gewählten 
Kodierung noch etwa 26 Bit für den eigentlich Schutz 
gegen Raten. Das alleine ist schon viel zu wenig, aber 
wenn man ein paar tausend IDs generiert, stellt man 
fest, daß es sich um die Ausgabe eines Zufallszahlen- 
generators mit einem 16-bit Seed handelt. Damit ist 
es ohne Probleme möglich, mögliche Vorgangs-IDs zu 
generieren, wobei man im Durchschnitt lediglich ca. 
32000 generieren muß, bis man ein Dokument trifft. 

Diese Dokumente, zu denen man sich so Zugang 
beschaffen kann, sind dann allerdings verschlüsselt. 
Die Frage ist, ob sie anständig verschlüsselt sind, und 
ob sie z.B. gegen Replay-Angriffe gesichert sind, ob 
ein Angreifer sich sein Metadon-E-Rezept duplizie- 
ren könnte. 

Andere Richtung 

Aber kann man vielleicht auch einen solchen Server 
direkt angreifen? Eine ISDN-Verbindung klingt ja wie 
eine sichere Sache. Von einem Beobachter einer Test- 
stellung in einem Krankenhaus haben wir erfahren, daß 
über das ISDN eine normale TCP/IP Einwahl durchge- 
führt wird, und daß der Server ein einfaches Windows 
NT 4.0 ohne Firewall oder Dienste-Zumachen war. Wir 
können also davon ausgehen, daß diese Systeme von 
einem dedizierten Angreifer in Minuten zu öffnen sind, 
nachdem er zuende gestaunt und fertig gelacht hat. 

Nachdem ein Angreifer das Server- System übernom- 
men hat, ergeben sich natürlich noch ganz andere 
Möglichkeiten. So kann der Angreifer z.B. "strings" 
über die Anwendung laufen lassen und dabei das 
Datenbank-Paßwort im Klartext auslesen. In der 
Datenbank stehen dann die ISDN-Rufnummern, die 
das System annimmt und zurück ruft. Ein leichtes also, 



sich hier als Angreifer einzutragen und dann die kom- 
promittierte Arztpraxis nicht mehr zu benötigen. Der 
Vollständigkeit halber sei noch gesagt, daß die sich auf 
dem Server einwählenden Clients üblicherweise Win- 
dows 98 Systeme sind, die noch leichter zu öffnen sind 
als die Server. Viele Ärzte werden da vermutlich auch 
direkt ihre File Shares drauf haben und die Patienten- 
daten direkt per SMB veröffentlichen, zum einfacheren 
Zugriff im LAN. Der Einsatz von Firewalls ist jedenfalls 
nicht vorgesehen im Konzept, haben wir uns versi- 
chern lassen. So etwas bräuchte man nicht, das sei ja 
alles sicher und überhaupt sei das Konzept mit Daten- 
schutzbeauftragten zusammen erstellt und von denen 
abgesegnet worden. 

Zusammenfassung 

Wir hatten bisher noch keinen Erfolg beim Versuch, 
uns ein solches Testsystem zur eigenen Begutach- 
tung zu beschaffen. Das ist allerdings geplant. Wir sind 
gespannt, was eine eigenhändige Analyse des Systems 
noch so alles ergeben wird. 

Was wir bisher von dem System gehört haben, erin- 
nert an eine Schlucht aus einem Indiana Jones Film, 
über die eine kleine wackelige Hängebrücke montiert 
wurde, und unser einheimischer Führer teilt uns mit, 
daß alles sicher sei, man solle einfach nicht nach unten 
gucken. 

Das PaDok-System ist lediglich das Backend für das 
Gesundheitskarte-Gesamtsystem. Das ist zweifelsoh- 
ne der wichtigste Teil, aber wenn hier schon derartig 
gepfuscht wird, was haben wir dann von dem Fron- 
tend-Teil zu erwarten? Wie sicher ist die Gesundheits- 
karte selber? Kann unser marodes Gesundheitssystem 
diese zusätzliche Belastung durch selbst erhackte E- 
Rezepte verkraften? 

Auch wenn man das Risiko für die Durchführung der 
skizzierten Angriffe für eher gering hält, ergibt sich 
doch die beunruhigende Tatsache, daß korrupte Ärz- 
te angesichts solcher Infrastruktur-Mißstände leichtes 
Spiel haben, weil sie sich immer auf Hacker im System 
berufen können. 

Angesichts dieser katastrophalen Umstände empfiehlt 
der CCC ausdrücklich, die Gesundheitskarte noch ein 
paar Jahre nach hinten zu verschieben, und die bereits 
bestehenden Komponenten und zukünftigen Plä- 
ne einer anständigen Analyse von neutraler Seite zu 
unterziehen. Immerhin wird hier mit Steuergeldern 
hantiert. Gerade in Zeiten von Hartz IV sind solche 
Verschwendungen (in PaDok und D2D sollen dreistel- 
lige Millionenbeträge geflossen sein) nicht zu rechtfer- 
tigen. Dafür hätte man hunderttausenden von sozi- 
al Schwachen helfen können, anstatt ihnen jetzt ihre 
Bezüge zu streichen. 

[1 ] http://www.kvno.de/mitglieder/d2d/faq_tech.html 
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Die Gefahren der 
Softwarepatente 

von Alexander Bernauer <alexander.bernauer@ulm.ccc.de> 

Der CCC Ulm hat zwei Chaosseminare zum Thema Softwarepatente veranstaltet. Am 
13. Oktober 2003 hat Christian Cremer, Patentanwalt aus Neu-ulm, das Patentsystem 
allgemein und den Übergang zu Softwarepatenten aus seiner Sicht als Patentanwalt 
dargestellt. 



Am 4. November 2004 hat Richard M. Stallman [1] 
einen Vortrag über die Gefahren der Softwarepatente 
gehalten [2]. Stallman ist als Gründer der Free Softwa- 
re Foundation [3] und der GNU Bewegung [4] beson- 
ders angagiert im Kampf gegen Softwarepatente. 
Jedoch wird nicht nur freie Software von Softwarepa- 
tenten bedroht, sondern fast alle, die im Bereich Infor- 
mationstechnik tätig sind, und im Grunde auch jeder 
Endanwender. Dieser Artikel greift die Inhalte und die 
Argumentationen aus beiden Vorträgen auf und gibt 
einen Überblick über Softwarepatente und ihre Kon- 
sequenzen. 

Ein Patente ist ein Monopol auf die Verwendung einer 
Idee. Softwarepatente sind damit Monopole auf die 
Verwendung von Ideen, die man in Software einsetzen 
könnte. Wichtig dabei ist, dass sich ein Softwarepa- 
tent sich nicht auf ein komplettes Programm bezieht, 
sondern auf eine Idee, die in vielen verschiedenen Pro- 
grammen eingesetzt werden könnte. 

Die ursprüngliche Idee des deutschen Patentsystems 
war, Erfindern einen Investitionsschutz zu gewähren 
und dafür im Gegenzug das neue Wissen für die Allge- 
meinheit zu erhalten. Jemand forscht an einer neuen 
Sache und veröffentlicht die Ergebnisse. Im Gegenzug 
bekommt er ein Monopol zur wirtschaftlichen Ausbeu- 
tung seiner Ergebnisse, um seine Investitionen für die 
Forschung wieder rein zu holen und Gewinn mit seiner 
Arbeit erzielen zu können. Nach einer gewissen Zeit 
läuft das Patent aus und das Wissen wird zum Allge- 
meingut. Der gewünschte Effekt des Patentsystems ist 
also die Förderung von Investitionen in die Forschung 
und damit die Förderung von Innovationen. 

Damit eine Idee in Deutschland patentierbar ist, muss 
sie vier Kriterien erfüllen. 

• Neuheit: Nach dem absoluten Neuheitsbegriff muss 
unter Berücksichtigung des allgemeinen Fachwissens 
zum Prioritätszeitpunkt die Erfindung neu sein. Das 



bedeutet auch, dass es mehrere Patente auf die selbe 
Idee geben kann. 

• Schöpfungshöhe: Unter Berücksichtigung des Stan- 
des der Technik und den Fähigkeiten des Durschnitts- 
fachmanns muss es sich um eine erfinderische Tätigkeit 
handeln. Das bedeutet insbesondere, dass die aufge- 
zeigte Lösung nicht naheliegend sein darf. Trivialpaten- 
te sind damit ausgeschlossen. 

• gewerbliche Anwendung: das Erfundene muss sei- 
ner Art nach geeignet sein, um in einem technischen 
Gewerbebetrieb hergestellt oder angewendet zu wer- 
den. 

• Technizität: die Erfindung muss technisch sein. Die 
gültige Definition von Technizität ist: planmäßiges 
Handeln unter Einsatz von beherrschbaren Naturkräf- 
ten zur Erzielung eines kausal übersehbaren Erfol- 
ges ohne menschliche Verstandestätigkeit zwischen- 
zuschalten, wobei der kausal übersehbare Erfolg die 
unmittelbare Folge des Einsatzes beherrschbarer Natur- 
kräfte ist. 

Patente auf Mathematische Methoden, Pläne und Ver- 
fahren für geschäftliche Tätigkeiten und Programme 
für Datenverarbeitungsanlagen sind zusätzlich explizit 
ausgeschlossen. 

Um für eine Idee einen Patentschutz in Deutschland zu 
erlangen muss man eine Anmeldung beim zuständigen 
Patentamt abgeben und eine Gebühr bezahlen. Nach 
einer formalen Überprüfung der Anmeldung folgt die 
Recherche zum Thema und die Offenlegung der origi- 
nalen Anmeldeunterlagen. Anschließen kommt es zur 
materiellen Prüfung in der sich ein technischer Patent- 
prüfer mit den Ergebnissen der Recherche beschäf- 
tigt und die Patentierbarkeit der Idee überprüft. Er ent- 
scheidet dann, ob das Patent erteilt wird, oder nicht. 
Wird es erteilt, so kann jeder dritte ein Einspruchsver- 
fahren starten, in dem er eigenes Material zur Erneu- 
ten materiellen Prüfung vorlegt. Das kann dazu führen, 
dass die Erteilung des Patentes zurückgezogen wird. 
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Nach einer gewissen Frist erlischt die Möglichkeit, ein 
Einspruchsverfahren anzustreben. Es bleibt jedoch die 
Möglichkeit, ein Nichtigkeitsverfahren anzustreben, bei 
dem sich ein Gericht mit der Gültigkeit eines Patentes 
beschäftigt. 

Patente werden oft mit Copyright oder Urheber- 
recht in einen Topf geworfen [5]. Das ist aber gänzlich 
falsch. Das Urheberrecht schützt die Arbeit des Erfin- 
ders, also eine konkrete Umsetzung einer Idee. Ein 
Patent bezieht sich aber auf die Idee selber und somit 
auf alle möglichen Arbeiten, die diese Idee umsetzen. 
Wenn jemand ein Programm schreibt, so kann er sicher 
sein, kein Urheberrecht zu verletzen, wenn er nichts 
kopiert hat. Nicht zu kopieren heißt aber nicht, dass 
man sicher kein Patent verletzt. Ein weiterer wichtiger 
Unterschied ist, dass der Schutz des Urheberrechts auf 
eine Arbeit automatisch wirksam ist, während man für 
eine Patentanmeldung drei Dinge braucht: Geld, Zeit 
und das Glück, es als Erster angemeldet zu haben. 

Im Lauf der Jahre hat sich die Praxis des Patentwe- 
sens von der anfänglichen Idee wegbewegt und wider- 
spricht mittlerweile den Grundsätzen von damals. Klar 
ist, dass man als Unternehmen zwar den Patentschutz 
für eine Idee haben, der Konkurrenz aber trotzdem so 
wenig Wissen wie möglich darüber vermitteln möch- 
te. Das führt dazu, dass die Patentschriften mit Absicht 
nur so viel über die Idee aussagen, um im Zweifels- 
fall mit ein wenig Interpretationshilfe ein Gericht über- 
zeugen zu können und sonst keine weiteren Details 
oder gar Hilfestellungen für einen Leser beinhalten. Die 
Kunst beim Formulieren von Patentschrif- 
ten, diesen schmalen Grat nicht 
zu verlassen, ist das Hand- 
werk der Patentanwäl- 
te. Damit wird der Vorteil 
eines Patentes für das 
Allgemeinwohl, die 
Erhaltung von Wis- 
sen über Neues, 
geschwächt. 

Die schwammi- 
ge Formulierun- 
gen in Patent- 
schriften führen 
dazu, dass sich 
ein Patenprü- 
fer schwer tut, 
einen Antrag 
zu bearbei- 
ten. Verständ- 
lich, dass sich 
ein Einzelner 
schwer tut, 
innerhalb kur- 
zer Zeit zu ent- 
scheiden, ob 
alle Kriterien 
für die Paten- 
tentierbarkeit 




erfüllt sind. Da es für einen Patentprüfer mehr Arbeit 
bedeutet, ein Patent abzulehnen, wird er es im Zwei- 
felsfall eher akzeptiert. Die Konsequenz sind Trivialpa- 
tente, mehrere Patente auf die selbe Idee und Patente 
auf bereits bekannte Ideen, wofür es jeweils genügend 
Beispiele gibt, wie z.B. ein Patent auf das Rad, das 
2001 in Australien erteilt wurde [6]. 

Das Kriterium "Technizität" verhinderte bislang die 
Patentierbarkeit von Software. Natürlich ist eine exak- 
te Trennung zwischen Softwarepatent und techni- 
schem Patent nicht einfach. In der Grauzone bewegt 
sich z.b. Software, die als zusätzlichen Seiteneffekt 
irgendwo ein Lämpchen blinken lässt. Da ein techni- 
sches Merkmal genügt, ist damit die Hürde der Techni- 
zität genommen. So gibt es mittlerweile eine Reihe von 
Patenten dieser Bauart, die sich eigentlich auf Softwa- 
re beziehen. Dazu kommt jetzt, dass man das Tech- 
nizitätskriterium so erweitern möchte, dass es offiziell 
möglich ist, Software zu patentieren. ... 

Falls Softwarepatente eingeführt werden, wird sich 
ein Programmierer überlegen müssen, was zu tun ist, 
um sicher kein Patent zu verletzen. Man müsste alle 
Ideen, die in der Software Verwendung finden, auflis- 
ten und einzeln auf die Existenz von Patenten abprü- 
fen. Das ist aber im Allgemeinen unmöglich. Zunächst 
einmal ist es nicht leicht, wirklich alle Strukturen und 
Ideen einer Software zu finden. Das liegt daran, dass 
man ein Programm auf viele verschiedene Arten struk- 
turieren kann. Zum Beispiel könnte man die Granula- 
rität bei der Analyse verändern und bekäme damit ein 
ganz anderes Bild von Einzelkomponenten und ihrem 
Zusammenspiel. Das Erstellen einer erschöpfenden 
Liste aller verwendeter Ideen erfordert eine viel 
höhere mentale Fähigkeit als das Schreiben 
des Programms. 

Angenommen man hätte aber tatsäch- 
lich die vollständige Liste der ver- 
wendeten Ideen: dann wäre es 
immer noch unmöglich, für jede 
Idee herauszufinden, ob sie 
patentiert ist. Das liegt zum 
einen an den sogenannten 
schwebenden Patenten. Das 
sind Anmeldungen auf 
Patente, die zwar schon 
eingereicht aber noch 
nicht veröffentlich 
wurden. Es kann also 
sein, dass sich erst spä- 
ter herausstellt, dass 
man ein Patent ver- 
letzt, ohne dass man 
eine Chance gehabt 
hätte, das im Vorfeld 
in Erfahrung zu brin- 
gen. Beispiel dafür ist 
die LZW Komprimie- 
rung, die im GNU Pro- 
gramm compress ein- 
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gesetzt werden sollte. Kurze Zeit vor dem Release der 
Software wurde ein US Patent auf diesen Algorith- 
mus erteilt. Selbst wenn man ein eigenes Patent für die 
Idee beantragt, bringt das in diesem Fall nichts, weil 
bei einem Konflikt immer derjenige den Zuschlag vom 
Patentamt bzw. vor Gericht erhält, der seinen Antrag 
als erster eingereicht hat. Ein weiteres Problem ist 
die Masse der existierenden Patente. Es sind so viele, 
dass das Durchforsten aller möglicherweise relevanten 
Patente bei weitem länger dauert, als das Schreiben 
der Software selber. Hinzu kommen die schwammigen 
und unklaren Formulierungen in Patenttexten, die die 
TTU (Time-To-Understanding) massiv verlängern. Stall- 
man erwähnte zum Beispiel ein US Patent auf topo- 
logische Sortierung, in dessen Patenttext der Begriff 
"topologische Sortierung" kein einziges Mal auftaucht. 

Es bleibt einem als Programmierer also nichts weiter 
übrig, als zu hoffen, kein Patent zu verletzen. Alter- 
nativ bleibt die Hoffnung, dass es niemandem auf- 
ällt, wenn man doch eines verletzt. Richard Stallman 
beschreib das bildhaft als "mit verbundenen Augen 
durch ein Minenfeld laufen (mit dem Unterschied, dass 
Minen nur einmal explodieren)". 

Falls man trotz aller Vorsicht ein Patent mit seiner Soft- 
ware verletzt, stellt sich die Frage, was man tun kann. 
Erstens kann man versuchen, die Verwendung der 
patentierten Idee zu vermeiden. Das kann einfach sein, 
es kann aber auch beliebig schwer werden. So gibt es 
zum Beispiel ein US Patent auf die Fast Fourier Trans- 
formation (FFT). Wenn man eine Software geschrie- 
ben hat, die die FFT verwendet, so kann man vielleicht 
auf die normale Fourier Transformation zurück grei- 
fen, da diese nicht patentiert ist. Wenn die Softwa- 
re aber ohnehin schon selbst auf den größten Maschi- 
nen am Resourcenlimit kratzt, so ist sie unbrauchbar, 
wenn man keine FFT einsetzen kann. Ein anderer Fall, 
in dem man nicht auf die Verwendung einer Idee ver- 
zichten kann, sind Spezifikationen, die die Verwendung 
bestimmter patentierter Algorithmen vorschreiben. Bei- 
spiele dafür sind PostScript und GIF. Die Implementie- 
rung gemäß der Spezifikation kann man vielleicht nicht 
umgehen, weil es sich um einen de-facto oder gar 
öffentlichen Standard handelt. Der Sinn von Software 
ist ja, dass sie benutzt wird. Wenn einer Software die 
Unterstützung vieler Standards fehlt, so wird sie kei- 
ne Akzeptanz bei Benutzern finden und ihre Entwick- 
lung damit sinnlos werden. Das gleiche gilt für Elemen- 
te der grafischen Benutzerschnittstelle, an die sich die 
Benutzer so gewöhnt haben, dass es schwer fällt, einen 
Ersatz zu finden, der das selbe vermittelt und vom 
Benutzer akzeptiert wird. Ein Beispiel dafür ist der Fort- 
schrittsbalken. Ein Problem hat man auch, wenn man 
es mit einem Patent zu tun hat, das eine ganze Familie 
von Ideen abdeckt. Ein Beispiel dafür sind US Patente 
auf Public-Key-Kryptographie. Hier kann man nicht auf 
die Verwendung der Idee verzichten, weil die Wissen- 
schaft keine Alternativen kennt. 

Eine zweite Möglichkeit im Falle der Verletzung eines 
Patents ist es, eine Lizenz für die Nutzung zu erlan- 



gen. Diese Lizenz stellt grundsätzlich der Inhaber des 
Patents aus. Er ist dazu aber nicht verpflichtet. Auch 
für die Nutzungsbedingungen gibt es keinen Rahmen, 
so dass man der Willkür des Inhabers ausgeliefert ist. 
Zusätzlich ist es so, dass man vielleicht mehr als eine 
Lizenz kaufen muss, weil mehr als ein Patent verletzt 
oder mehrere Patente auf die selbe Idee existieren. 

Letzteres darf zwar gemäß Patentrecht nicht sein, 
kommt in der Realität aufgrund der schwammigen For- 
mulierungen in den Patenttexten aber durchaus vor. 
Die Kosten für Lizenzen sind damit ein unkalkulierbares 
Risiko für Unternehmen. Erfahrungen aus den USA zei- 
gen, dass wenige Lizenzen genügen, um den Business 
Plan eines Unternehmens zu sprengen und damit sei- 
nen Tod zu bedeuten. 

Als letzte Möglichkeit bleibt ein Nichtigkeitsverfah- 
ren anzustreben. Man müsste dafür zeigen, dass eines 
der Kriterien für dieses Patent zum Vergabezeitpunkt 
nicht erfüllt war. Außer dem Neuheitskriterium sind alle 
anderen subjektiver Natur, so dass ein Gericht im All- 
gemeinen wahrscheinlich die damalige Entscheidung 
des Beamten respektieren wird. Es bleibt also nur die 
Möglichkeit, Beweise dafür zu finden, dass die Idee 
damals nicht neu war. Das kann in Einzelfällen gelin- 
gen. Im Allgemeinen gibt es jedoch selten beglaubig- 
te Dokumente, die den Einsatz einer Idee zu einem 
bestimmten Zeitpunkt bestätigen. Selbst wenn man 
den Prozess gewinnt, so hat man viel Geld und Zeit 
verloren, was wieder die meisten Business Pläne spren- 
gen dürfte. 

Alle drei Möglichkeiten können gangbare Wege sein. 
Im Allgemeinen wird man jedoch selten das Glück 
haben, für jedes Patent, das man verletzt, einen der 
Wege gehen zu können und dabei insgesamt zu über- 
leben. Scheitert man ein Mal, ist das Projekt tot. Und 
dabei ist im Vorfeld nicht abzusehen, mit wie vielen 
Forderungen von Patentinhabern man konfrontiert 
werden wird. In der Konsequenz werden sich weni- 
ger Unternehmer auf dieses unkalkulierbare Spiel ein- 
lassen, so dass die Einführung von Softwarepatenten 
für die Softwarebranche weniger Investition und damit 
weniger Innovation bedeuten würde. Beides Dinge, die 
das Patentwesen eigentlich fördern wollte. 

Softwarepatente haben jedoch nicht nur Nachtei- 
le, sonst würde es niemanden geben, der ihre Ein- 
führung fordern würde. Der Vorteil von Patenten ist 
im Allgemeinen, dass man Geld durch die Vergabe 
von Lizenzen verdienen kann. Außerdem hat man ein 
Instrument zur Kontrolle des Marktes, weil man Kon- 
kurrenten beliebig ausschalten kann, wenn man ein 
Patent auf eine Schlüsseltechnologie besitzt. Dafür 
braucht man aber Patentanwälte, die bezahlt wer- 
den wollen. Außerdem kann es ebensogut sein, dass 
ein Konkurrent ein Patent auf eine Schlüsseltechnolo- 
gie besitzt, was für das eigene Unternehmen negative 
Konsequenzen haben kann. 
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Der Nachteil von Softwarepatenten überwiegt also den 
Vorteil deutlich, so dass sich die berechtige Frage stellt, 
wie sich das überhaupt für irgend ein Unternehmen 
rechnen kann. Der Antwort darauf lautet: Lizenzaus- 
tausch. Die Idee ist folgende: man hat stapelwei- 
se Patente, so dass man einen Patentinhaber im Fal- 
le einer Verletzung seines Patentes seinerseits wegen 
Patentverletzung verklagen kann. Das funktioniert, 
weil sich in der Menge der schwammig formulierten 
Patente im Normalfall immer mindestens eines finden 
lässt, gegen das der andere mit etwas Interpretations- 
hilfe verstößt. Diese Situation der gegenseitigen For- 
derung lässt sich dann einfach auflößen, in dem man 
sich gegenseitig Lizenzen zur Verwendung des Paten- 
tes gibt. 

Die Ameldungen und die Verwaltung der Patente, 
das Finden von günstigen Patenten, die sich für For- 
derungen gegenüber andere eignen sowie das Aus- 
handeln und Verwalten der Lizenzen ist ein sehr gro- 
ßer Aufwand, für den ein Unternehmen im Normalfall 
eine eigene Abteilung mit Patentanwälten braucht. Es 
ist klar, dass sich das nicht jedes Unternehmen leisten 
kann. Daher sind es meistens Megakonzerne, die die- 
se Strategie verfolgen. Es folgt, dass man nur Zugang 
zu gewissen Technologien bekommt, wenn man zum 
Kreis der Megakonzerne gehört und sich damit den 
Zugang erzwingen kann. Der Nachteil der Softwarepa- 
tente, das unvorhersagbare Belangen durch Patentin- 
haber, ist somit kompensiert und es bleiben die Einnah- 
men durch Lizenzen und die Kontrolle des Marktes. 

Vor allem in der Informatikbranche ist die Kontrol- 
le des Marktes ein wichtiger Punkt. Zum einen gibt 
es fast monatlich neue Technologien und Ideen, die 
in ein Produkt implementiert Erfolg am Markt brin- 
gen können. Diese Schnellebigkeit der Branche macht 
es aber für marktkontrollierende Unternehmen schwer, 
den Überblick zu behalten. Außerdem braucht es im 
Gegensatz zum Ingenieurswesen viel weniger Start- 
kaptial, um ein Unternehmen zu gründen und mit 
Hilfe einer guten Idee Erfolg am Markt zu erlangen. 
Im Zweifelsfall tun es ein paar PCs aus dem nächs- 
ten Supermarkt und eine Hand voll Entwickler. In der 
Konsequenz gibt es ständig neue Unternehmen, die 
aus dem Nichts hervortreten und den Etablierten den 
Markt streitig machen. Mit Hilfe von Softwarepatenten 
wäre die Gefahr für Megakonzerne gebannt. 

Ironischerweise lässt sich das am besten an Hand einer 
Argumentation von Befürwortern zeigen, und zwar am 
Mythos des 'Starving Genius' (verhungerndes Genie): 
Gegeben ein Genie, das eine tolle Erfindung hat und 
sich jahrelang in seiner Garage einschließt um die Idee 
zu implementieren. Wenn er damit fertig ist, grün- 
det er ein Unternehmen, um die Früchte seine Arbeit 
zu ernten. Jetzt kommen aber die etablierten Konzer- 
ne der Branche, klauen ihm die Idee und drücken mit 
ihren Kapitalreserven die Marktpreise. Das arme Genie 
kann diesem Konkurrenzdruck nicht Stand halten, weil 
ihm das Kapital fehlt. Er geht zu Grunde. Das Patent- 
system soll ihn jetzt vor den Großen schützen, da diese 



seine patentierte Idee nicht klauen dürfen und er somit 
in Ruhe sein geniales Produkt kommerziell verwerten 
kann. Hört sich gut an. 

Doch die Realität ist eine andere. Das Genie wird zwar 
- mit etwas Geld und Geduld - ein Patent auf seine 
Idee erhalten, und ein Konkurrent wird dann seine Idee 
nicht klauen dürfen, da er sonst das Patent verletzt. Im 
Gegenzug jedoch verletzt das Genie mit seiner Soft- 
ware sehr wahrscheinlich gleich mehrere Patente von 
Megakonzernen. Das liegt ganz einfach daran, dass die 
Konzerne so viele schwammige Patente besitzen, dass 
sich mit hoher Wahrscheinlichkeit einige finden lassen, 
die sich auf irgend einen Teil der Software des Genies 
beziehen. Das Genie sieht sich somit mit einer Gegen- 
forderung konfrontiert. Als einzigen Ausweg bietet die 
Konkurrenz einen üzenzaustausch an. Wenn das Genie 
es nicht schafft, die Forderungen abzuwehren ohne 
dabei finanziell zu Grunde zu gehen, ist sein Unterneh- 
men tot. Geht er auf den Lizenzaustausch ein, gibt er 
sein Monopol auf seine Idee auf, so dass der Mega- 
konzern nun doch mit ihm auf dem Markt konkurrie- 
ren kann. Beide Fälle sollte das Patentsystem eigent- 
lich verhindern. 

Eine anderes Argument von Befürwortern ist, dass es in 
anderen Branchen auch Patente gibt. Warum nicht in 
der Informatik? Auch hier wollen Unternehmen Inves- 
titionsschutz. Wo ist der Unterschied? Grundsätzlich 
gilt es hier zu bedenken, dass diese Argumentation nur 
greift, wenn man das Patetensystem an sich als etwas 
Positives anerkennt. Ohne die Grundlagen des Paten- 
system hier diskutieren zu wollen, wirft zumindest die 
gängie Praxis schwere Zweifel am Vorteil für die Allge- 
meinheit auf. Doch selbst wenn die Praxis den eigent- 
lichen Ideen des Patentsystems folgen würde, gibt es 
grundsätzliche Unterschiede zwischen der Informatik 
und Ingenieursbranchen, so dass die Veraussetzungen 
für ein Patentsystem mit Vorteil für die Allgemeinheit 
nicht gegeben sind. 

Software ist Mathematik. Eine Software läuft auf einer 
universellen Maschine mit einer Spezifikation. Die- 
se Spezifikation ist eine mathematische Beschreibung 
der Funktionalität der Maschine. Die Anwendung die- 
ses universellen Machine, ein Programm, ist damit eine 
Sammlung von mathematischen Beschreibungen. Es 
liegt in der Natur von mathematischen Beschreibun- 
gen, dass sie umformuliet werden können, ohne ihre 
Aussage zu ändern. Der Zusammenhang zwischen 
zwei mathematischen Beschreibungen für die selbe 
Aussage ist im Allgemeinen nicht offensichtlich. Des- 
halb kann es einem Patentprüfer einfach passieren, 
dass er ein Patent auf eine Idee vergibt, die eigent- 
lich schon patentiert ist; noch eher als bei technischen 
Patenten, wo das selbe allein auf Grund der schwam- 
migen Formulierungen in den Patenttexten in der Ver- 
gangenheit schon geschehen ist. "Ein Patent pro Idee" 
wird sich also für Softwarepatente kaum halten lassen, 
was jedoch ein zentraler Aspekt eines Patentsystem ist. 
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Viele Probleme eines Ingenieurs stellen sich für einen 
Informatiker gar nicht: Resonanzfrequenzen, EMV, 
Verschleiß, Robustheit gegenüber Umwelteinflüs- 
sen, usw. Vor allem gibt es in der Informatik keine Dis- 
krepanzen zwischen den Modellen und der Realität. 
Wenn man annimmt, dass Informatiker und Ingenieu- 
re im Schnitt die selbe Intelligenz besitzen, dann folgt 
daraus, dass ein Software viel komplexer aufgebaut 
werden kann, bevor die Probleme darin die menta- 
len Fähigkeiten des Entwicklers überschreiten. Je kom- 
plexer ein System ist, desto mehr Einzelkompontenten 
sind im Allgemeinen darin verbaut. Deshalb verletzt 
eine typische Software gleich mehrere Softwarepaten- 
te, was u.a. dem starving Cenious das Genick bricht. 

Alle oben beschriebenen Probleme mit der gängigen 
Praxis bei Patenten würden sich bei Softwarepaten- 
ten ergeben, selbst wenn die gängige Praxis sich an 
die Ideen des Patentsystems halten würde. Realistisch 
betrachtet werden sich also die Probleme mit Patenten 
für die Informatikbranche verschärfen. Eine geschlos- 
sene Gemeinschaft von Megakonzernen wird sich bil- 
den, die sich den Markt aufteilen und gemeinsam kon- 
trollieren. Für den Endanwender bedeutet das, dass es 
kaum Alternativen zu einer Software geben wird, und 
man sich mit seinen Wünschen komplett in der Hand 
und damit in der Willkür einzelner Unternehmen befin- 
det. 

Die Investitionskosten in der Informatikbran- 
che sind im Vergleich zu denen aus Inge- 
nieursbranchen sehr viel kleiner. Das liegt 
daran, dass man keine Labore und Produkti- 
onshallen mit vielen Auflagen, teuere Mess- 
geräte, Maschinen und Spezielwerkzeuge 
braucht. Der Inverstitionsschutz ist deshalb 
nicht so zentral wie in anderen Branchen. 
Deshalb stellt sich die Frage, ob es hier auch 
legitim ist, dafür die Freiheitsrechte anderer 
zu beschränken und staatlich durchzusetzen, 
was das Patentsystem tut. 

Es wird argumentiert, dass es falsch wäre, 
wenn sich andere an den Früchten der Arbeit 
eines Erfinders bereichern. Deshalb muss 
ein Patentsystem her, auch in der Informa- 
tik. Das ist aber falsch. Man tut dabei so, als 
ob die geniale Idee aus dem Nichts entstan- 
den wäre, ohne jegliches Vordenken und 
ohne Inspiration durch Ideen anderer. Das ist 
aber fast nie der Fall. Warum darf der Erfin- 
der alles Vorwissen umsonst nehmen um 
es dann, wenn er es mit einer Idee von sich 
angereichert hat, auf einmal den anderen 
vorzuenthalten? Das ist nicht konsequent. 
Man müsste alle seine Vordenker entlohnen, 
und eigentlich deren Vordenker auch. Es ist 
klar, das das nicht praktikabel ist, weshalb 
es auch niemand ernsthaft fordert. Doch 
eigentlich ist es der einzig richtige Weg, 
wenn man die Entlohnung von Erfindern ver- 
langt. Deshalb ist diese Forderung falsch. 



Richard Stallman vergleicht Software mit Musik. Beides 
ist eine Komposition von bekannten Einzelteilen und 
bei beiden besteht die Kunst darin, bekannte Elemente 
so zusammenzusetzen, dass schöne Musik bzw. gute 
Software entsteht. Ab und zu findet jemand ein neues 
Element das er in ein Gesamtwerk aus sonst bekannten 
Elementen einbettet. Angenommen, es gäbe Patente 
auf Musik. Wie genial hätte dann ein Mozart oder ein 
Bethoven sein müssen, um Musik zu komponieren, die 
erstens von den Leuten akzeptiert wird und zweitens 
keine bis dahin bekannten Elemente verwendet? Da 
der Sinn von Musik ist, gehört zu werden, würde ein 
Komponist mit diesem Problem konfrontiert werden. 
Genau das selbe Problem hat ein Programierer, der 
Software schreiben will, die vom Benutzer verwendet 
wird. Es ist einfach nicht möglich, Software zu schrei- 
ben, ohne dabei bekannte Ideen zu verwenden. 

[1] http://www.stallman.org/ 

[2] http://ulm.ccc.de/chaos-seminar/rms/video-de.html 
[3] http://www.free-soft.org/ 
[4] http://www.gnu.org/ 

[5] In Deutschland gibt es kein Copyright Gesetz, son- 
dern das Urheberrecht. Die Unterschiede sind für die 
Argumentation aber bedeutungslos. 

[6] http://www.ipmenu.com/archive/AUI_2001W0012.pdf 
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Teaching Hacking 



Most universities teach Information security - if at all - in a defensive way. Offen 
things like intrusion detection Systems, f irewalls and encryption are covered, but 
topics like buffer overflows or forensics are forgotten. To change this, the Laborato- 
ry for Dependable Distributed Systems at RWTH Aachen University offered a Summer 
School on applied IT security and this article will present our experiences. 



If you take a look at the courses offered at major uni- 
versities in the world, you will notice that most of 
them do not care about practical security, aka hacking. 
Instead, they teach theoretical foundations (e.g. 
encryption and hash functions) or defensive approa- 
ches like intrusion detection Systems, firewalls and Vir- 
tual private networks. In our view, this leaves Compu- 
ter science graduates ill-prepared fortheirjob because 
they lack hands-on knowledge on how to deal with 
security technology or they always trail active adversa- 
ries in their efforts to master them. To understand the 
importance of information security, students should 
have the possibility to gain practical experience how 
security Systems fail, using offensive techniques. And 
hacking is fun, so teach it :-) 

In summer term 2004 the Laboratory for Dependable 
Distributed Systems at RWTH Aachen University offe- 
red a novel course in the area of information security: 
The Summer School "Applied IT Security" gave gradu- 
ate and Ph.D. students an insight into common tech- 
niques in the area of information security. Düring a 
three week period, we covered topics like 
exploiting of programming errors, wire- 
less (in-)securities and malware. 

Because some people from the CCC in 
Cologne and Berlin were involved - either 
as lecturer or attendee - we want to pre- 
sent our experiences and give an insight 
into the course. At first we want to give 
an overview over related courses at other 
s we Dresent in 



ty of Technology, Germany, regularly runs a so-called 
"Hacker Contest" for several years. 

The Hacker Contest is similar to a Linux Deathmatch, 
as organized at some Congresses and the Camp: Stu- 
dents form teams that have to set up Systems and then 
use common exploitation techniques to attack the Sys- 
tems of the other teams. The attendees also have to 
analyze attacks to their own Systems and increasingly 
deploy stronger defense measures. The University of 
Magdeburg and our Lab also offer a similar lab course. 

There are some universities that offer courses in which 
the students learn the underlying concepts of offensive 
IT security and can also apply their knowledge. As an 
example, the Distributed Systems Group of the Tech- 
nical University of Vienna offers courses on Internet 
security: Practical aspects of IT security like race condi- 
tions, viruses and reverse engineering are covered and 
exercises in which the students have to implement the 
attacks must be solved. 



detail our Summer School. 

[Hacking at other universities] 

There have been some good attempts to 
incorporate practical elements of infor- 
mation security into university degree 
courses. For example, the Computer sci- 
ence department of Darmstadt Universi- 
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http://www.auto.tuwien.ac.at/~chris/teaching/inetsec2.html 
http://www.infosys.tuwien.ac.at/teaching/courses/lnetSec2/ 
index.html 

"Wargames" and "Capture the Flag" (CTF) contests 
are also offered at some universities. Most famous is 
probably the annual CTF contest of the UCSB, in which 
several educational institutions spread across the world 
battle against each other. This year, a team from our 
Lab has also competed against the other teams. Surpri- 
singly, we managed to achieve the second place :) 

The Information Technology and Operations Center 
(ITOC) at the U.S. Military Academy West Point has 
a curriculum which also teaches offensive information 
security techniques. ITOC organizes a yearly "Cyber 
Defense Exercise" which has similarities to the Captu- 
re the Flag contests. U.S. authorities with an informa- 
tion security education branch like the United States 
Military Academy, the United States Air Force Acade- 
my, and the Naval Postgraduate School, participate in 
these exercises. Machines maintained by the partici- 
pants are attacked by the NSA 92nd Aggressor Squa- 
dron -- Land Information Warfare Activity, over the 
course of several days and participants have to coun- 
ter these attacks. 

[Summerschool] 

After pointing out some other courses in the area of 
information security, we now want to give an overview 
over the Summer School, especially on the schedule 
during these three weeks. 

The staff organizing the Summer School consisted of 
two research assistants of the Laboratory and two stu- 
dents of whom one is a research Student of the labora- 
tory and the other a regulär Student at another univer- 
sity. Three of them are or were involved with the CCC 
in Cologne. 



The intended audience were students and young sci- 
entists from Europe with a profound interest not only 
in information security but also in offensive techni- 
ques in relation to security. Applicants had to fill out 
a questionnaire and we chose fifteen people. Most of 
them study at RWTH Aachen University, but we had 
also four attendees from the University of Cambridge 
(three of them from Ross Anderson's security group) 
and two from TU Berlin (also members of CCC Berlin). 
Furthermore, someone from netric.org, a CCC Cologne 
member and a Student from the University of Applied 
Science in Gelsenkirchen attended. So a motley crew 
of people - partially with profound knowledge - parti- 
cipated at the Summer School. 

At our Lab, we had to prepare a few things before- 
hand: To foster informal communication between stu- 
dents, we converted an office to a coffee hall with 
sofas, an overall relaxed ambiance, and a choice of 
snacks and refreshments. A lab room was converted to 
some kind of hackcenter, most exercises were hosted 
in this room. Furthermore, there was a piain room for 
temporary use by students which had the feeling they 
need concentration for specific tasks. The housing was 
left to the students themselves and their choices sho- 
wed a very Wide variety of Solutions ranging from the 
universities' guest-house to the local camping ground. 
Three week long camping is hard, but they survived it 
without problems. 

Lectures started at a quarter to nine in the morning 
(due to the Verpeilungsfaktor, most lectures began 
later...) and covered two topics until noon. After lunch, 
the lab Session started, during which students applied 
the techniques leamed in the lectures and developed 
them further. For an outline of the Summer School see 
the following table. 

The lab Session was interrupted by a so called "coffee 
table talk": We invited external contributors to give a 
short Statement related to a topic of their interest or 





Lecturei 


Lecture2 


Lab 





Lecturei 


Lecture2 


Lab 


I-I 


Introduction 


Hardware 
Security 


Hardware 
Wargames 




Introspection 


Projects 


Projects 


1-2 


Web 

Applications 


Web 

Applications 


Web 

Applications 


II-5 


Projects 


Projects 


Projects 


i-3 


Buffer Overflows 


Other Program- 
ming Errors 


Exploiting 
Overflows 


iii-i 


Mise. Forensics 


Disk Forensics 


Forensics 


1-4 


Advanced 
Exploitation 


Networking 


Network 
Programming 


III-2 


Disk Forensics 


Disk Forensics 


Forensics 


i-5 


Sniffing: Layer 

I&2 


Spoofing & 
(D)Dos 


Sniffing £ 
Spoofing 


in-3 


Malware Unix 


Unix infection 


Honeynets 


ii-i 


Network 
Topology 


Application 
Fingerprinting 


Network 
Mapping 


111-4 


Excursion 


Excursion 


Excursion 


II-2 


Bluetooth 


Wireless Attacks 


Wardriving 


111-5 


Wargame 


Wargame 


Wargame 




Hidden Data 


Honeynets 


Wardriving 


Table: Schedule of the Summer School 
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a short introduction one some project they work on. 
The coffee table talks were intended to broaden the 
view of the participants. We aimed at showing the stu- 
dents problems being worked on in the real world and 
to teach them looking at problems not only from the 
security perspective. 

Speakers were sent by corporations ranging from Mic- 
rosoft and Pixelpark up to TÜV Rheinland and a major 
German Bank. But we had also participants from other 
groups like the CCC orthe "Verein digitale Kultur", 
which Covers artistic expression via digital means, and 
various academic research groups. Topics covered in 
the coffee table talk ranged from computer-ethics, civil 
liberties in relation to the Internet, infos about phishing 
attacks, up to technical subjects like heap-based over- 
flows and XML security. 

A typical day 
ended with a 
meeting: usu- 
ally around six 
in the evening 
everybody pre- 
sented his work 
of the day. But 
students offen 
stayed through 
large parts of 
the night to 
develop their 
projects further. 

[[Running 
the School]] 

[[[First week]]] 

On the first day 

(September 20) we started with a brief introduction 
and covered "Hardware Hacking". The students got 
an insight into limitations and vulnerabilities of hard- 
ware devices. Düring the lab Session, the students ope- 
ned some devices (e.g. cable modems, router, Swit- 
ches) to inspect the insides. They also played some 
wargames like www.hackthispage.tk and averaged at 
about five levels. 

The topic of the second day was "Attacks Against Web 
Applications": One lecture concentrated on gene- 
ral problems in web applications (e.g. SQL injection 
and cross Site Scripting), while the other had the spe- 
cial focus on programming errors on web-applicati- 
ons written in PHP. The corresponding lab Session had 
no very tight focus. The students should find bugs in 
real web applications. In the afternoon, George Dane- 
zis, one of the participants and research assistant at the 
university of Cambridge, gave a talk on "Anonymous 
Communication". 

On Wednesday, the lectures concentrated on buffer 
overflows and other programming errors. This is a very 
broad topic and probably two lectures are not enough 




to cover the whole field. Therefore, these two lectures 
concentrated on the basics and two other coffee table 
talks deepened the knowledge of the participants. The 
lab Session was quite populär at this day: The students 
should exploit various programs and they apparent- 
ly had much fun doing this. One Student also found 
some bugs in real applications (e.g. a format-string 
vulnerability in Tor, an anonymizing overlay network 
for TCP) and further examined them. In Cooperation 
with the authors of the Software, these holes are now 
fixed - so no Oday for you now :). 

"Phishing" was the topic of the coffee table talk and 
an IT-security specialist of a large German bank explai- 
ned the threat. 

A lecture on "Advanced / Automatic Exploitation" 

showed the partici- 
pants some techni- 
ques and tools that 
attackers can use, 
e.g. the Metasploit 
Framework, search 
engines like Google 
to collect Informa- 
tion, etc. In additi- 
on, the art of fuz- 
zing, a technique 
to find errors in a 
given program in 
a semi-automated 
fashion, was presen- 
ted. The second lec- 
ture repeated neces- 
sary knowledge on 
communication net- 
works and gave an 
introduction to net- 
work programming 
and the important libraries (e.g. libnet, libpcap). Imp- 
lementation of covert Channels, ARP-spoofing and 
various other tools were the focuses of the lab Sessi- 
on. Jens Ohlig from the CCC gave a historical over- 
view about political activism and hackers during the 
coffee table talk. 

On Friday, sniffing & spoofing and (distributed) deni- 
al-of-service (DDoS) attacks were covered. The lec- 
tures gave an overview of tools and techniques used 
to sniff passwords and other sensitive information on 
networks. The lectures also explained how to spoof 
packets in order to receive interesting packets and 
gave a background on (distributed) denial-of-service 
attacks. 

During the lab Session, the Student experimented with 
the available tools and also implemented some small 
programs for ARP-spoofing and similar techniques. The 
coffee-table talk entitled "XML Security" was given by 
Christian Geuer-Pollman from the European Microsoft 
Innovation Center (EMIC), Aachen. 



1 
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[[[Second week]]] 

The next week started with a lecture on network 
reconnaissance. This lecture covered techniques to find 
useful information about targets and first Steps of an 
attacker after a successful compromise. The second 
lecture focused on further Steps after an intrusion and 
covered application fingerprinting in depth. The stu- 
dents were encouraged to do portscans of the network 
of our university during the lab Session. The center for 
Computing and communication (CCC) explicitly allo- 
wed us to do this and we found some security holes 
during these tests: One Student found several rou- 
ters with default passwords and another tracked down 
some printers that could be managed remotely via a 
web-interface. Penetration-testing for phone-systems 
was the topic of the coffee-table talk on this day. Rolf 
von Stein from TÜV Secure IT explained the motivation 
behind this and gave some background information. 

Wireless Security was the focus on Tuesday: The first 
lecture with the title "Bluetooth Security" introduced 
the attendees to the basics of the Bluetooth Standard 
and pointed out some attacks. The focus of the second 
lecture was on WLAN (mainly 802.11b) and also a 
small introduction to RFID and its concerns was given. 
During the afternoon, the students did wardriving and 
found more than 100 wireless LANs in total. The ques- 
tion "Where is information security today and what in 
the future?" was answered during the coffee-table talk 
by Dogan Kesdogan, a researcher from RWTH Aachen 
University. 

In the evening, we had a social event: We drank beer, 
ate pizza and watched "Office Space" and some 
movies from the demo scene - perhaps a typical eve- 
ning for hackers :) 




On Wednesday we demonstrated some of the cur- 
rent research topics of our Lab: The first lecture cove- 
red "Hidden Data In Documents" and explained that 
there are many interesting data in proprietary formats 
that can be misused. The second lecture gave an intro- 
duction to honeynets and related security research. 
Like the day before, interested students had the possi- 
bility to search for wireless LANs in the city. Some par- 
ticipants stayed at the lab and developed their projects 
further. One project was especially interesting: One 
attendee wrote a crawler which automatically searches 
for images with an included thumbnail in the Exif hea- 
der. At the end of the Summer School, he had down- 
loaded about 3.000.000 images, from which about 
one percent had a significant difference between the 
image and the included thumbnail. This shows that a 
significant amount of images has interested data hid- 
den inside the document itself. More on this at the 
Congress, At this day, one of the students prepared the 
coffee-table talks: llja van Sprundel filled with his talk 
on heap-based overflows a gap that was left by the 
lectures on programming errors. 

The rest of the week gave the students the possibili- 
ty to do some research on their own and implement 
novel techniques. To prepare this, we collected ideas 
for further research on Thursday morning. From Thurs- 
day noon until Friday evening, the participants had 
time to implement their projects. The resulting pro- 
jects covered tools for covert Channels and fingerprin- 
ting applications. 

Furthermore, a fuzzing framework and low level net- 
work libraries were implemented and an embedded 
device was introspected. The coffee-table talk on Fri- 
day gave an insight into the relation between pro- 
ject management and security. Rainer Lingmann from 
Pixelpark gave a talk entitled "IT- Security: Das Gret- 
chenprojekt aus Projektmanagment Sicht". 

[[[Third week]]] 

The last week started with 
two lectures about Compu- 
ter forensics. These lectu- 
res covered the basic of disc 
forensics and gave an intro- 
duction on Computer foren- 
sics in general. During the 
lab Session the students had 
to solve a game: We gave 
them a Compact Flash card 
which we pretended to have 
retrieved from a suspec- 
ted terrorist. They had the 
task to reconstruct the cor- 
rupted files and retrieve as 
much information as possib- 
le, especially the place and 
time for the next "terrorist 
meeting". It was much fun 
and many students were able 
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to recover the damaged files. The second task for this 
afternoon was forensic imaging of used hard discs that 
we had previously bought at ebay. The students found 
some hard discs which contained interesting Informa- 
tion: One disc was obviously the former hard disc of a 
cashier terminal or cashier Computer because we found 
bills and accounting information on it. 

Another hard disc was used in a bookstore before and 
contained many hundreds of e-mails with partially sen- 
sitive information. And a third hard disc was obvious- 
ly used in a mailbox and the students were able to 
reconstruct the user database. How to realize "Soft- 
ware Detection of Currency" was presented by Steven 
Murdoch, a participant 
of the Summer School 
and Ph.D. Student 
from Cambridge. 

An external guest gave 
two lectures on Tues- 
day: Knut Eckstein 
from the NATO C3 
Agency talked about 
"Advanced Filesys- 
tem Forensics - Jour- 
naling Filesystems". 
More forensics of disk 
images was the topic 
of the lab Session. This 
was too much foren- 
sics, and the students 
got bored. Düring the 
coffee table talk, fdO 
from CCC Cologne 
gave a talk about grse- 
curity. 

The lectures on Wednesday concentrated on malwa- 
re for Linux. The first talk gave a general introduction 
to the topic and presented rootkits and backdoors. In 
contrast to that, the second lecture concentrated on 
code infection for ELF binaries. Düring the lab Session, 
the students deepened the knowledge gained during 
the lectures and some wrote ELF modification code. 
One of the students provided a small challenge for the 
lab Session: Lisa Thalheim prepared an ELF binary and 
posed some questions. Again, the coffee table talk was 
prepared by llja van Sprundel. He talked about for- 
mat-string attacks and filled another gap that was not 
covered during the lectures on exploitation of pro- 
gramming errors. 

An excursion to some abandoned industrial Sites was 
arranged for Thursday. We wanted to have an alter- 
nation to the usual schedule and therefore organized a 
trip to a coking plant in Essen, a gasholder in Oberhau- 
sen and some geocaching locations in Wuppertal. The 
main goal for this tour was fun and getting to know 
each other better. 



We used the last day of the Summer School to get 
feedback on the three weeks. But the highlight of this 
day was the Wargame with several levels and incre- 
asing difficulty, which Christian Klein had prepared 
beforehand. It offered the students the possibility to 
apply all techniques they had learned in the previous 
days. Fun prevailed during this game, with some minor 
exceptions due to missing tools. 

[[After the Summer School]] 

After the three weeks, some further noteworthy things 
happened. The participants of the Summer School had 
submitted six talks to the Chaos Communication Con- 
gress and all six Submission were accepted for presen- 

tation. The par- 
ticipants of the 
Summer School 
also agreed to 
meet at the Con- 
gress again. You 
will probably 
recognize us by 
ourt-shirts :) 

The biggest les- 
son we learned: 
Hacking is fun 
for students. For 
example, when 
the students 
exploited their first 
buffer overflow, 
they were very 
enthusiastic and 
worked hard to 
learn more. 

At the end of the Summer School participants were 
asked to fill out a questionnaire to give use some poin- 
ters for improvements. In summary, the feedback was 
mostly positive. The main criticisms were: 

• Three weeks are too long, especially if the students 
have to work so hard and spend so much time at the 
courses as they did 

• Some lectures need improvements, on one hand the 
depth of the talks and on the other hand the under- 
standability 

In conclusion, the concept of the Summer School was 
very sound and it is already planned to repeat that 
event in 2005. 

You can find our wiki used during the Summer School 

at http://weltwissen. koeln. ccc. de/wiki/index.php/ 
Summerschool_Aachen_2004 

It has links to all slides and photos. 
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Deutsche Homeland-Security: 
E-Mail-Überwachung 2005. 

Volker Birk <volker.birk@ulm.ccc.de> 

Flirten, Lästern, Tratschen. Und wir lesen Ihre Mails mit: Die Polizeien und Geheim- 
dienste! Ein Blick auf ein Neusprech- Dokument der besonderen Art: die TKÜV. 



Nun ist es soweit: die wohl anrüchigste Maßnahme 
im Rahmen der Telekommunikationsüberwachungs- 
verordnung - kurz TKÜV - wird, längst beschlossen, 
ab dem 1 .1 .2005 Wirklichkeit in Deutschland. Die E- 
Mails sind's diesmal, die der Staat furchtbar gerne mit- 
lesen möchte. 

Von vielen unbemerkt ist diese Verordnung auch zum 
E-Mail-Überwachen längstens Realität; allein eine 
"Gnadenfrist", formuliert in § 30 "Übergangsvorschrif- 
ten", bewahrte die Maildienstleister bisher, jetzt schon 
Überwachungsschnittstellen für Polizeien und Geheim- 
dienste in die Mailserver einzubauen. Diese Gnaden- 
frist läuft nun an Neujahr ab. 

Damit schafft es die Regierung, gleich zwei Grundrech- 
te der Bürger auf einen Streich ad absurdum zu führen: 
das Brief- und das Fernmeldegeheimnis (beide Art. 10 
GG). Und wie es inzwischen üblich ist, erlegt unse- 
re Regierung die Kosten dafür den Providern auf - der 
Staat ist halt grade knapp bei Kasse, da muss man Ver- 
ständnis haben. 

Was sind schon Arbeitsplätze, wenn es 
um die Staatssicherheit geht? 

Es darf jetzt jeder seine private E-Mail-Überwachung 
selber bezahlen, denn die E-Mail-Anbieter legen die 
Kosten natürlich auf die Verbraucher um - was sollen 
sie auch sonst machen? 20.000 EUR und mehr kostet 
allein so eine "Überwachungseinrichtung" pro Stück, 
so der Verband der deutschen Internetwirtschaft, ECO. 
Ab 64.000,- EUR erhält der "verpflichtete" Provi- 
der auf dem Markt eine "Komplettlösung" zur Spit- 
zelei. Eine Summe, die manchem Maildienstleis- 
ter zu schaffen macht. Kein Pappenstiel also in einem 
hart umkämpften Markt, in dem es um tausende von 
Arbeitsplätzen geht. 

Diese Kosten gehen nämlich vor allem kleineren Provi- 
dern, die zwischen 1 .000 und 10.000 Kunden haben, 
an die Substanz. So erklärte beispielsweise Canhost, ein 
Provider aus Hamm, seinen Kunden in einer Rundmail, 
dass ihn diese Maßnahme der Bundesregierung dazu 
zwinge, die "enormen Kosten ... auf den Endkunden" 
umzulegen. Pro Kunde werden so jeweils zunächst mal 



5 EUR fällig, die dieser Kunde für die Bespitzelungsins- 
tallation für seine eigenen Mails beisteuern darf. 

Martin Seeger von NetUse, einem Provider in Kiel, 
geht davon aus, dass die Kosten fürs Abhören künftig 
15 Prozent der Telekommunikations-Preise ausmachen 
werden. Hoffen wir mal alle, dass die Kunden dieses 
und vieler anderer Provider Verständnis zeigen werden 
- und nicht zu E-Mail-Providern im Ausland wechseln 
werden, die von der Maßnahme nicht betroffen sind. 
Zu Providern, deren Arbeitsplätze im Ausland sind. 

lieschenSgmx.de? Aber bitte CC an den 
Verfassungsschutz, nicht wahr? Oder 
besser gesagt: BCC. 

Denn merken darf der Bespitzelte davon natürlich 
nichts (bzw. der "Teilnehmer" unter seiner "Ken- 
nung", wie es im Beamtendeutsch heisst). Den Provi- 
dern ("Verpflichtete") wurde gleich ein Maulkorb mit 
auferlegt. So heisst es in § 15 "Verschwiegenheit": 

(1) Der Verpflichtete darf Informationen über die Art 
und Weise, wie Überwachungsmaßnahmen in sei- 
ner Telekommunikationsanlage durchgeführt werden, 
Unbefugten nicht zugänglich machen. 

(2) Der Verpflichtete hat den Schutz der im Zusam- 
menhang mit Überwachungsmaßnahmen stehenden 
Informationen sicherzustellen. Dies gilt insbesondere 
für Informationen darüber, welche und wie viele Ken- 
nungen einer Überwachung unterliegen oder unter- 
legen haben und in welchen Zeiträumen Überwa- 
chungsmaßnahmen durchgeführt worden sind 

Oder anders formuliert: Bespitzeln müssen die Provi- 
der, aber sie dürfen niemand was davon sagen. Schon 
gar nicht dem Bespitzelten selber. 

Kontrolle? Ach was, wozu denn, habt 
Vertrauen! 

Das reicht doch, wenn die jetzt schon mit vielen Auf- 
gaben überladene Regulierungsbehörde für Telekom- 
munikation und Post bei Interesse mal ins Protokoll 
schauen darf (§ 17). 
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An obligatorische Prüfung, wozu denn eigentlich über- 
wacht wurde, und warum das so notwendig war, und 
wieviel Bespitzelung und damit Grundrechtsverletzung 
denn nötig ist, um zu den doch erfahrungsgemäß recht 
bescheidenen Ergebnissen zu kommen, daran wurde in 
der gesamten Verordnung in keinem der 31 Paragra- 
phen gedacht. 

Und das, obwohl der Nutzen der ganzen Spitze- 
lei höchst fragwürdig erscheint; die Zahl der Spitzel- 
maßnahmen ist zwar insgesamt explosionsartig nach 
oben gegangen - bei der Telefonüberwachung z.B. von 
4.674 Maßnahmen 1995 auf 24.441 Maßnahmen in 
2003. Ein ähnliches Verhältnis wird wohl auch bei der 
E-Mail-Überwachung zu beobachten sein. Der große 
Ermittlungserfolg dagegen durch die massive Abhörak- 
tion stellte sich nicht ein - es ist nichts wesentliches 
Erfreuliches in der Hinsicht zu beobachten. 

In einem Rechtsgutachten zur Telefonüberwachung, 
das die Bundesregierung beim Max-Planck-Institut für 
ausländisches und internationales Strafrecht, Freiburg, 
beauftragt hat, kommen die Experten deshalb auch zu 
einer kritischen Sicht der Zustände im (Noch-)Rechts- 
staat. So erklären die Gutachter, dass der gesetzliche 
Richtervorbehalt nicht gelockert werden dürfe. Auch 
seien Berichtspflichten für die Strafverfolgungsbehör- 
den zur Kontrolle der Entwicklung bei Überwachungs- 
maßnahmen notwendig. Der Umfang der Benach- 
richtigungspflichten von Betroffenen sei zu erweitern. 
Gespräche zwischen Beschuldigten und zeugnisverwei- 
gerungsberechtigten Personen dürften grundsätzlich 
nicht verwertet werden. Der Umfang des Straftatenka- 
taloges des § 100 a Strafprozessordnung müsse wie- 
der reduziert werden; dieser wurde in den letzten Jah- 
ren ständig erweitert. 

Statt nun diese Probleme anzugehen, die das Max- 
Planck-Institut ihrem Auftraggeber, der Bundesregie- 
rung, ins Stammbuch geschrieben hat, tat die Bun- 
desregierung lieber - nichts. Und jetzt kommt die 
E-Mail-Überwachung dazu. 

Das alles ist doch nur gut für Euch, wir 
fangen damit die bösen Terroristen! 

Schaut man z.B. die Personen um Mohammed Atta an, 
so erblickt man Männer, die an der TU Hamburg-Har- 
burg Elektrotechnik studiert haben, junge Leute, die 
mit dem Netz groß geworden sind. Und die sollen kei- 
ne Ahnung haben, wie man der Überwachung ent- 
geht? 

Es ist imer dasselbe Argument, das ständig in unseren 
Ohren klingelt: wir müssen Eure Bürgerrechte ignorie- 
ren, weil wir Terroristen jagen. Dazu richten wir jetzt 
Bespizelungsmöglichkeiten für Euer Privatleben ein. 
Aber treffen diese Maßnahmen überhaupt auch die 
Zielgruppe? Immerhin bedeuten sie eine Grundrechts- 
verletzung für alle deutschen Bürger, da muss dann 
aber schon gewaltig was rüberkommen an Ergebnis, 



wie soll sonst das Prinzip der Verhältnismäßigkeit noch 
gewahrt bleiben? 

Tatsächlich aber gilt wohl eher: es 
kommt so gut wie gar nichts bei rüber. 

Nur ein geistig sehr armer Terrorist wird ausgerech- 
net über deutsche E-Mail-Dienstleister mailen - und 
das noch unverschlüsselt - so dass Polizei und Geheim- 
dienst mitTatütata ausrücken und ihn verhaften kön- 
nen, wenn er seine subversiven Abmachungen per 
deutschem Webmailer an eine deutsche Mailadresse 
absendet. Ein Szenario, das eher in den Bereich "nur in 
Deinen Träumen, mein sehr junger Padavan" fällt, als 
in den Bereich "realistische Projekte". 

Die Bespitzelung wirkt nur bei den Leuten, die kein 
PGP einsetzen - oder Ihre Nachrichten nicht per Mail, 
schon gar nicht über leicht zu überwachende SMTP- 
Server laufen lassen. Die gesamte Truppe um Atta war 
aber nicht durch besondere Ignoranz und technisches 
Unvermögen, sondern von Kompetenz und organisa- 
torischem Sachverstand geprägt. 

Wie will man von solchen Leuten erwarten, dass sie 
unverschlüsselt per Mail kommunizieren über über- 
wachte Dienste? Man wird es nicht erwarten können. 
Und das wirft die Frage auf: wer soll hier wirklich über- 
wacht werden? 

Willkommen in Ozeanien! 

Das Ministerium für Wahrheit erklärt, dass alle die- 
se Maßnahmen notwendig und sinnvoll sind, gleich 
welche Kritik die unwissenden Mahner wie die Rie- 
ge der Datenschutzbeauftragten oder irgendwelche 
Rechtsgutachter auch immer äußern werden. Deshalb 
braucht ihr vor allem eines nicht: OpenPGP. 

Was Ihr da am allerwenigsten braucht, findet Ihr unter 
http://www.gnupg.org. Bitte setzt es auf keinen Fall ein, 
erst recht nicht in Zusammenarbeit mit 

http://www.mozilla.org/proiect5/thunderbird/ und 
http://enigmail.mozdev.org/ 

So helft Ihr mit, dass wir auch in Zukunft die Maßnah- 
men des Ministeriums für Frieden unterstützen kön- 
nen, Frieden und Glückseligkeit über die Welt zu ver- 
breiten. 

"Those who would give up liberty for a Utile tempora- 
ry safety deserve neither liberty nor safety and will 
lose both. " (Benjamin Franklin) 

Links: 

http://www.bmwa.bund.de/Redaktion/inhalte/Pdf/ 
TKUEV1,property=pdf.pdf 
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Ein Friedensangebot im 
Kampf ums Copyright 

von Matthias "werter" Mehldau <wetter@ccc.de> 

Als Kompromiss zwischen faschistischem Kontrollsystemen für Musik und anar- 
chischen Zuständen in Filesharingnetzwerken wird die Kulturflatrate vorgeschla- 
gen. 



Der Kampf ums Copyright im Internet ist entflammt 
und die Fronten sind klar: Auf der einen Seite stehen 
die Computerfreaks als technische Anführer der Inter- 
netrevolution. Sie entwickeln ständig neue Raffinessen, 
um "ihre" Musik Kopieren und Tauschen zu können. 
Auf der anderen steht die Musikindustrie. Sie möch- 
te "ihre" Musik mit immer neuen Kopierschutzmaß- 
nahmen davor schützen, unerlaubt kopiert zu werden. 
Mit periodischen Klagewellen sollen rechtsbewuss- 
te Filesharinguser von illegalen Downloads abgehal- 
ten werden. 

Für die mächtige Musikindustrie sieht es allerdings 
schlecht aus: Die Technik und der Geist von Filesha- 
ring ist aus der Flasche und lässt sich nicht wieder ein- 
holen. Lieber möchten die Manager Songs wie bis- 
her verkaufen, als ob sie weiterhin an einen physischen 
Träger gebunden seien. Doch die dazu notwendigen 
Kopierschutzsysteme wurden nun immer aufs Neue 
von Teenagern geknackt und auch künftig werde ich 
immer, wenn ein Song meine Ohren erreichen kön- 
nen soll, ihn auch aufzeichnen können. DRM - 
Digital Restrictions Management - zwecklos. 

Doch so dramatisch braucht die Diskussi- 
on nicht geführt zu werden. Beide Sei 
ten wollen ja nur, was ihnen zusteht: 
Der Musikhörer will privat Musik 
kopieren dürfen - etwa auf CD 
unter Freunden oder herun- 
tergeladen aus einem Files- 
haringnetzwerk. Der Musik 
macher möchte von seiner 
Kunst leben können 




und seine Kosten gedeckt haben. Dieser Wunsch wird 
von der Musikindustrie deutlich übertriebener formu- 
liert, als es der Musiker tut, um im Wesentlichen ihren 
Profit zu maximieren. 

Laut der GEMA verdienen Musiker heute ihr Geld zu 
etwa je einem Drittel durch Konzerte, Merchandi- 
sing und dem CD-Verkauf. Doch der Musikhörer ist 
schon lange in der Lage, auch anders Musik zu emp- 
fangen: Aus dem Radio kann er Musik auf aufneh- 
men, etwa auf Kassette. Um sicherzustellen, dass der 
Musiker auch für diese Kopien Geld bekommt, fliesst 
eine Abgabe vom Kassettenpreis an die Ver- 
wertungsgesellschaft für Musiker, die 
Gema. Nach diesem Prinzip gibt es 
I bereits seit den 60er Jahren Pauschal- 
abgaben auf leere Kopiermedien (Kas- 
"jTf setten, CDs, DVDs) und Kopiergeräten 
\ j (Brenner, Fotokopierer), die auch an die 
I Verwertungsgesellschaften für Bild, Ton, 
VI Wort und Film gezahlt und von diesen 
unter den Urhebern aufgeteilt werden. 

Künftig gibt es keinen absehbaren 
Grund, weshalb durch das Internet weni- 
ger Konzerte besucht und T-Shirts gekauft 
werden. Da der Mensch bequem ist, wür- 
den wohl aber weniger CDs verkauft - 
das würde genauso passieren, wenn es 
Musik im Netz nur noch kopierge- 
schützt und direkt kaufbar gäbe. Im 
Netz können allerdings grade klei- 
ne Musiker einfach Alben im Netz 
anbieten und direkt 



#85 / 2004 



dip ddlpruLhlpudpr 



22 



FLATRATE OHNE UPSTREAM 



1 




Eine fast in Vergessenheit geratene Tradition bei der Datenschleuder: Kabelbilder. Was bei der 2600 die "Payphones 
from around the World" sind bei uns Leserfotos von aussergewöhnlichen Kabelsituationen. Besten Dank geht an Enno 
Lenze für das oben abgebildete Prachtexemplar! Keep 'em comin'! 



vertreiben. Wer meint, keine CDs zu brauchen, aber 
die Musik trotzdem geil findet, kann über elektronische 
Bezahlsysteme auch kleine Beträge freiwillig spenden. 

Nun, wenn aber freiwillig nichts passiert im Land der 
Schmarotzer, braucht es Zwang: Die Pauschalabga- 
be, als Kompensation für Privatkopien in Deutschland 
erfunden, soll auf Computer oder Internetzugänge 
ausgedehnt werden. Für fünf Euro im Monat würden 
nicht-kommerzielle Kopien über Filesharingnetze ver- 
gütet und die Kosten für unwirksame Kopierschutzsys- 
teme und wahnwitzige Strafverfahren gespart, lauten 
die Argumente der Befürworter. Sie sind bei Netzak- 
tivisten, wie dem Chaos Computer Club, den Glo- 
balisierungskritikern attac und bei grünen Politikern 
zu finden. Für diese sind Kopierschutzsysteme schon 
allein aus bürgerrechtlichen Gründen tabu: Der gläser- 
ne Musikhörer soll nur in den Köpfen der Datenschüt- 
zer existieren. Um die Forderung nach einer solchen 
"Kulturflatrate" zu manifestieren, haben sie Anfang 
Dezember die Kampagne "Fairshahng" ins Leben 
gerufen, auf deren Website [1] dazu Unterschriften 
gesammelt werden. 

Aber gleich zu einer general-verpflichtenden Pauscha- 
labgabe - auch wenn sie den schönen Namen "Kul- 



turflatrate" trägt - zu greifen, scheint manchem über- 
zogen: Braucht es eine verpflichtende Vergütung im 
Netz - oder können sich Musiker anpassen und der 
Markt reguliert sich von selbst? Zwischen diesen bei- 
den Modellen - Kopierschutz und Pauschalabga- 
be - bewegt sich die Freiwilligkeit. Was wäre, wenn 
jeder, aus seiner Sicht angemessen, seine Lieblingsmu- 
siker bezahlt? Es wäre spannend zu beobachten, wie 
es guten und schlechten Musikern ergeht, die diesen 
Weg wagen. Noch eine abschließende Überlegung: 
Als "verpflichtende Freiwilligkeit" lässt sich das "Stra- 
ßenkünstler Protokoll" umschreiben; Dabei veröffent- 
licht Musiker sein nächstes Werk erst dann, wenn ihm 
seine Fans einen Betrag gezahlt haben, von dem er 
meint, dass er das Recht wert ist, seinen Song privat 
zu kopieren. 

Es gibt durch die Internetrevolution nicht nur mehr 
ungeahnte Probleme, sondern auch noch mehr unge- 
ahnte Lösungsmöglichkeiten. Das Musikgeschäft ist 
an einem Punkt, an dem es wagen und ausprobieren 
muss. Das Problem der Vergütung von geistigem Gut 
im Netz ist eine sehr brisante: Sie stellt sich gleicher- 
maßen auch für Filme, Texte und Fotos. Die Musiker 
befinden sich hier in einer Vorreiterrolle. 
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/join silcnet 

von Alien8 <fb@c3d2.de> 



Was waren das für Zeiten, als das Internet noch frei von Flash-Animationen, vorge- 
schriebenen Impressen und Anwälten war? 



Eigentlich egal. Die heutigen Zeiten sind nicht weni- 
ger spannend. Studenten netze rüsten auf, sich von den 
Schilys dieser Zeit beschüffeln zu lassen, MP3 Tauscher 
werden hart aber gerecht bestraft und Steuergelder die 
einst für die Entwicklung des Netzes dienten, werden 
jetzt ausgegeben, um Überwachungsbots für Chatka- 
näle zu schreiben. Wahrlich, es werden noch wunder- 
same Dinge geschehen. 

Zeit, die Klartext-Urgesteine des Internets abzulösen. 
Was für telnet recht ist, sollte für IRC billig sein. Die- 
ser Artikel soll Lust auf *das Chat* und Instant Mes- 
sagingsystem SILC (Secure Internet Live Conferencing) 
machen, es kurz vorstellen. 

Was braucht es also für ein Chatsystem, damit es 
authentifizieren und verschlüsseln kann? Könnte man 
nicht, wie bei http, einen SSL Layer einziehen? Nein, 
denn was für eine Client/Server Verbindung entworfen 
wurde, muss nicht auf Systeme mit mehreren Servern 
und unzählig vielen Clients passen. Mal vom Zertifi- 
kats-Dilemma abgesehen, wie können mehrere Cli- 
ents den selben Sessionkey nutzen? Woher weiß man, 
dass die Session wirklich bis zu jedem Client verschlüs- 



selt und authentifiziert ist? Das Protokoll gibt es jeden- 
falls nicht her. 

Initiert von Pekka Riikonen, einem Finnen - (was 
sonst?), wird SILC seit '96 entwickelt. Mittlerweile 
kann man es gut nutzen. Die Clientversion ist über 1.0 
hinaus, Gaim z. B. unterstützt es seit ein paar Versio- 
nen, die Server Software und das Toolkit stehen kurz 
vor der 1 .0. 

Meldet sich ein Client beim Server an, wird zu erst mit- 
tels Diffie-Hellman ein Session Key ausgetauscht. Der 
Server wählt die Methoden für Cipher, Hash, HMAC 
und Public Key Funktion aus dem aus, was der Client 
anbietet. Das heißt Silc Key Exchange (SKE) Protokoll. 
Ausgerüstet mit einem Sessionkey authentifizieren sich 
die Kommunikationpartner per Passphrase oder Public 
Key über eine Challange. Momentan werden nurSILC- 
eigene Keys unterstützt, OpenPGP- und X.509-Zer- 
tifikate sind vorgesehen. Damit sind der Client und 
der Server gegen Man-in-the-middle Attacken so gut 
geschützt wie bei ssh: "First time's free, kid". Die Fin- 
gerprints der Server gibt's auf http://silcnet.net. 
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Natürlich kann aus Performance- und Redundanzgrün- 
den nicht alles über einen Server laufen. Also muss es 
mehrere Server geben, die wiederum mit einem soge- 
nannten SILC-Router verbunden sind. Dieses Konstrukt 
nennt sich Cell. Die Router lassen sich auch miteinan- 
der verbinden und bilden einen Ring. Fällt ein Router 
aus, reden die anderen über ihre Backup-Router. Das 
Konzept nennt sich Hybrid Ring-Mesh. 

Nachrichten werden also von Client A zum Server über 
den Router wieder zum Server und schließlich zum Cli- 
ent B übertragen. Alles authentifiziert und verschlüs- 
selt. Dem aufmerksamen Leser wird es schon aufge- 
fallen sein: der Server, oder besser noch der Router, ist 
ein idealer Punkt, die Kommunikation abzuhören. Er 
muss alle Nachrichten ent- und verschlüsseln. Um die- 
se Schwäche zu umgehen, haben die Protokollentwick- 
ler eigene Keys vorgesehen. D. h. die Server schalten 
einfach auf Message pass through und mitlesen kann 
nur, wer auch den Key (preshared oder public) kennt. 
Den Trade-off Bequemlichkeit vs. Kontrolle kann jeder 
selbst wählen. 

Was kann man damit nun so anfangen? Bei einem 
Chatsystem ist das nicht schwer zu erraten. Channel- 
namen müssen nicht mit "#" beginnen. Nicks kön- 
nen doppelt vorkommen, Fingerprints nicht. Damit 
sind Nickwars passe. Der Founder eines Channels kann 
diesen als permanent setzen. Authentifiziert wird der 
Founder über seinen Public Key, wenn nich anders 
angegeben. Dieser beruft weitere Operators, die im 
Channel ihre Vorstellung von Ordnung durchsetzen 
können. Wenn man schon ein Schlüsselpaar hat, kann 
man Nachrichten ähnlich PGP natürlich auch signieren, 
was dem Leser nur nützt, wenn er den Public Key vor- 
her geladen 
und überprüft 
hat. Vorsicht! 
Da Nicks nicht 
eindeutig sind, 



erscheinen akzeptierte Keys immer als gültig, auch 
wenn der Nick wechselt. Filetransfer läuft über sftp 
sozusagen Peerto Peer. Die Schlüssel werden perSKE 
ausgehandelt und die Datei danach direkt von Client 
zu Client geschickt. Mittels von irssi bekannten Scripte- 
rweiterungen kann man den Client erweitern. Eine net- 
te Sache ist die silc-mime.pl Erweiterung. Damit lassen 
sich Dateien an einen Channel schicken, die per .mail- 
cap einer Applikation vorgeworfen werden können. 

Eine andere nützliche Sache ist, dass man eine SILC 
Session detatchen kann. Damit bleibt man im SILC 
Netzwerk, kann z. B. den Client updaten und bekommt 
seine Session zurück. 



Die Clients 

Der Standard ist silc-client, ein irssi-Ableger, der, wie 
das irssi-Plugin, von cOffee gepflegt wird. Grafische 
Clients gibt's im gtk-Gewand, silky war zuerst da, 
Alleskönner Gaim unterstützt SILC seit ein paar Versi- 
onen, auch wenn sich das noch nicht bei allen Paket- 
Maintainern rumgesprochen hat, sowie einen auf irs- 
si basierenden IRC/SILC-GUI-Client für MacOS X mit 
Namen Colloquy. 

Beim Verbinden zu einem Server sollte man beachten, 
dass silc.silcnet.net round-robin DNS verwendet. Ggf. 
kommt man besser, wählt man sich einen in seiner 
Nähe aus. IPv6 ist natürlich auch kein Problem. 

Hoffentlich hat Euch das ganze hier etwas Lust 
gemacht, mal SILC auszuprobieren. Wenn es noch 
Fragen gibt oder Ihr einfach einen Startpunkt in SILC 
sucht: /join c3d2 

CU there! 
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whois «</» 

von Mirko Swillus <mechko@thur.de> 



Wohin in Deutschland, wenn man sich als chaosnahen Hacker versteht und gleich- 
gesinnte sucht? Gibt es vielleicht in der Nähe Treffen von kompatiblen Wesen? Sind 
die dort Anwesenden auch echte Nerds? Um diese Fragen zu klären gibt die Redak- 
tion Datenschleuder Erfakreisen und solchen, die es werden wollen, Gelegenheit, 
sich vorzustellen. Hier nun eine Selbstdarstellung des Chaostreff und Erfa-Kandi- 
daten Dresden. 



Es dämmerte bereits, als er sich auf den Weg ins 
Hechtviertel machte. Er hatte schon den ganzen Nach- 
mittag überlegt, wie er wohl den Abend zubringen 
sollte und war zu keinem rechten Entschluss gekom- 
men. Seine Kommilitonen hatten schon am Mittwoch 
angekündigt, Freitag "mal wieder ordentlich einen 
trinken zu gehen". Aber die Vorstellung, am Freitag 
Abend in einer der zahlreichen Neustädter Kneipen 
ein Bier nach dem anderen zu kippen und zum Schluss 
völlig fertig im "Dürüm Döner" zu versauern, fand er 
nicht gerade sehr verlockend. 

Die Jungs im silc hatten ebenso keine Perspekti- 
ve gehabt, und man hatte daraufhin gemeinsam 
beschlossen, sich spontan im "Büro" zu treffen. Er 
musste grinsen, als er an die neue Bezeichnung ihres 
gemeinsamen Raumes in einem alten, völlig unsani- 
erten Haus dachte. Schon wegen dem Zustand der 
Immobilie war sie ein Kracher. So blöd ist das allerdings 
nun auch nicht, dachte er weiter, immerhin organi- 
sieren wir da auch wichtige Sachen. Früher mussten 
sie sich dafür immer in Neustädter Kneipen tref 
fen, was schon auch Vorteile hatte, allerdings 
kamen die wichtigen Dinge da immer etwas 
zu kurz, wie er fand. Viel macht man ja auch 
im silc und über das wiki, aber so ein Tref- 
fen ist da eben doch besser. Damals bei 
der Vorbereitung für das große Sym- 
posium "Datenspuren - Privatsphä- 
re war gestern." waren die Treffen, 
weil in Kneipen überm Bier abgehal- 
ten, meistens auch arm an Ergebnis- 
sen geblieben. Trotzdem hatten sie 
es zum Schluss reissen können und 
die eintägige Veranstaltung mit 300 
Besuchern und 20 Referenten zum 
Erfolg führen können. Noch heu- 
te ist ihm der Dreiklang "Daten- 
schutz. Privatsphäre. Bürgerrechte." 
im Ohr, den sie damals unter der 
Warnung "Ich weiss, was Du letzten 



Sommer gemailt hast." auf zwanzigtausend Postkar- 
ten gedruckt und damit ganz Dresden geflutet hatten. 
Seitdem war ihm klar, dass die Gruppe was erreichen 
konnte, dass das hier neben Spaß am Gerät auch eine 
ernsthafte Veranstaltung ist, dass es um was geht. So 
ernsthaft, dass sie mittlerweile auch ein Büro braucht, 
musste er wieder grinsen. 

Inzwischen hatte er den Rand der Neustadt erreicht. 
Immer größer wurde der Strom von jungen Leuten, 
die ihm mit bierdurstigen Gesichtern entgegenkamen. 
Wie so oft versuchte er, die Leute bestimmten Subkul- 
turen zuzuordnen und diese dann nach Häufigkeit zu 
ordnen. Und wieder nahm er es am Ende seiner klei- 
nen Erhebung mit einem leisen Grunzen hin, dass die 
Gruppe "Yuppie" am stärksten vertreten war. Freitag 
Abend eben. 

Als er in die Hechtstraße einbog, überlegte 
er, welcher Subkultur er sich wohl 
selbst zuordnen würde. Rein 
äußerlich würde 
das schon 
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schwer werden, vielleicht so eine Mischform zwi- 
schen Gruppe Linksalternativ, den Emocore-Poppern 
und der Öko-Abordnung. Vom Aussehen her gibt es 
den Typ "Hacker" jedenfalls schon mal nicht, da war 
er sich sicher. Denn er hatte nicht das Gefühl, dass die 
Leute, die zu den c3d2-Themenabenden kamen, fri- 
sur- oder klamottentechnisch in irgendein Muster pass- 
ten. Immerhin veranstalteten sie diese Abende seit nun 
schon fast einem Jahr, und bei durchschnittlich einer 
Veranstaltung im Monat mit immerhin 60 bis 70 Gäs- 
ten kann man da schon von äußerlicher Repräsentativi- 
tät sprechen, wie er fand. 

Und "innerlich"? Niemand bezeichnet sich selbst 
als Hacker, jedenfalls nicht, ohne danach ein echtes 
Glaubwürdigkeitsproblem zu haben, soviel ist mal klar. 
Auf der anderen Seite haben die Punks, mal als Bei- 
spiel, selten Probleme, sich selbst als Punk zu bezeich- 
nen - oder später irgendwann mal weintrinkend im 
Ledersessel zu sagen "Das war damals, in meiner 
Punkzeit". Da kann man schon neidisch werden, dach- 
te er. Aber er fühlte sich doch zugehörig und irgendwie 
heimisch bei den Dresdner Hackern. Ansonsten wür- 
de er kaum seinen Freitagabend mit ihnen verbringen, 
dachte er weiter. 

Er kam auf seinem Weg immer weiter ins Hechtviertel 
und wie jedesmal überkam ihn ein Gefühl der Vertraut- 
heit. Hier hatte er sein Leben in Dresden begonnen 
und dann einige Jahre gewohnt. Als er noch neu in der 
Stadt war, war er ab und zu einem der Usergruppen- 
Treffen gegangen. Aber dort stellte er bald fest, dass 
es da eben tatsächlich nur um das jeweilige speziel- 
le Interesse ging, ob nun bei der Linux User Group 
oder dem Unix-Stammtisch. Ihm fehlte neben den 
Diskussionen über die technische Funktionsweise die 
Frage nach der gesellschaftlichen Auswirkung. Vor 
welchen Entwicklungen haben wir Angst, wodurch 
werden diese bedingt und vor allem: Was können 
wir tun? 

Ein paar Punks grölten auf der anderen Straßenseite 
durcheinander, und er glaubte einen Ramones-Klas- 
siker wiederzuerkennen. Die Häuser waren hier zum 
größten Teil unsaniert, die noch bezahlbaren Mie- 
ten und die Nähe zur Neustadt hatte eine speziel- 
le Mieterklientel angezogen, was das Hechtviertel 
mit einem ganz eigenen Charme erfüllte. Sicherlich 
gab es solche Konstellationen auch woanders in der 
Republik, allerdings war dies für ihn typisch Osten. 
Im Gehen stellte er nun die Theorie auf, dass der 
Chaostreff sich in der Anfangszeit auch deswegen 
so schnell entwickelt hatte, weil Dresden als Stadt 
vielleicht besonders fördernde Eigenschaften für die 
Bildung solcher kleinen Gruppen bietet. Oft hatte 
er den Satz "Dresden ist wie ein groß ausgedehn- 
tes Dorf" gehört. Immerhin mit Technischer Univer- 
sität, mehreren Fachhochschulen und angesiedelten 
Halbleitergrößen. 

Der Osten an sich scheint jedenfalls nicht sonderlich 
fördernd für chaosnahe Aktivitäten zu sein, überleg- 



te er weiter. Von Berlin (Ost) abgesehen, gab es nach 
seinem Wissen keine nennenswerten Chaosaktivitä- 
ten. Früher hatte er ab und an mal was von Chaos- 
treffs in Weimar oder Jena gehört, aber seit einiger Zeit 
schienen auch die nicht mehr zu leben. Während er 
in die Straße einbog, in der das Haus mit dem "Büro" 
lag, fragte er sich, warum Ost und West auch in dem 
Punkt immer noch verschieden waren. Er erinnerte sich 
dabei an eine der nächtlichen Diskussionen auf dem 
17C3. Sie saßen damals komplette Nächte bei elektro- 
nischer Musik und Clubmate in der Lounge und rede- 
ten über Verschwörungstheorien oder Marxismus. Ein- 
mal ging es auch darum, dass gerade die Ostler durch 
ihre Geschichte ein natürliches Gefühl zu dem haben 
müssten, was der Club im Westen unter "Hacken" 
verstand. Kreativer Umgang mit Technik als fester 
Bestandteil des Alltags, polytechnische Schulbildung 
als eine der Voraussetzungen dafür. Aber die Landkar- 
te der Chaostreffen und Erfakreise zeigte im Gegen- 
satz zu diesen Theorien im Osten praktisch nur wenig 
Punkte, wie er wieder wehmütig feststellte. 

Er fragte sich, wer wohl schon da war, als er die Zah- 
lenkombination in das elektronische Türschloss ein- 
gab. Und schon im Treppenhaus hörte er die bekann- 
ten Stimmen aus dem "Büro". Er freute sich auf den 
Abend, auf die Nacht. Und er freute sich, dass c3d2 
nicht nur für ihn wichtig war, sondern auch für eine 
immer größer werdende Gruppe. Mit interessanten 
Leuten, einer stabilen Struktur - und sogar einem eige- 
nen Büro. 
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ICMP 2 - Koffeinsucht stillen 
und in der Sonne chillen 



von Lars Weiler <pylon@ccc.de> 



Campen macht dem gemeinen Hacker immer mehr Spaß. So ist es nicht verwun- 
derlich, dass in den Jahren zwischen den großen Camps, wie dem Chaos Com- 
muncation Camp oder jenen in den Niederlanden, ein kleineres Camp stattfindet. 
Schließlich wollen die Zelte auch genutzt werden, [i] 



Bei grandiosem Sonnenschein und über 30°C im Schat- 
ten haben etwa 100 Personen vom 5. bis 8. August 
2004 den Weg ins fränkische Münchsteinach gefun- 
den. Münchsteinach? Irgendwo habe ich das schon 
mal gelesen.... Klar, denn dort ist der Firmensitz der 
Loscher KG [2], dem Hersteller der köstlichen Club- 
Mate [3], ein auf Mate-Basis hergestellter Eistee, der 
in Hackerkreisen seit einigen Jahren sehr beliebt ist 
und auf den üblichen CCC-Veranstaltungen zu erwer- 
ben ist. 

So kam vor drei Jahren die Idee auf, in die geheimen 
Hallen des Herstellers vorzudringen und gleichzei- 
tig nebenbei ein wenig zu Campen. Der weniger als 
eine halbe Stunde Autofahrt entfernt liegende Erfa- 
Kreis Erlangen/Nürnberg/Fürth [4], in seiner Form als 
Bits'n'Bugs e.V., übernahm federführend die Organi- 
sation der Veranstaltung. So konnte eine anliegende 
Wiese des Sportplatzes vom SVS Münchsteinach zum 
Campen genutzt werden. Da dieser etwa einen Kilo- 
meter abseits vom Ort liegt, brauchten wir uns kei- 
ne großen Sorgen über 
die Belästigung von 
Anwohnern machen. 

Seit der ersten ICMP 
im Jahre 2002 hat der 
Sportverein ein schi- 
ckes WC- und Dusch- 
haus gebaut, so dass 
keine Einbußen in 
der Hygiene in Kauf 
genommen werden 
mussten. Dixi ade! 
Das nahe Freibad mit 
Naturquellwasser sorg- 
te für die kühle Erfri- 
schung bei Tage von 
Außen und die im 
Kühl-Anhänger gela- 
gerten Getränke der 
Loscher KG von Innen. 




Ii 

I ttl 




Insbesondere der "Partner- Tarif" - zwei 
Getränke zum Preis von eineinhalb - kon- 
struierte ein interessantes soziales Netzwerk, 
um sich gegenseitig ein Getränk auszuge- 
ben. 

Ein großes Bierfest-Zelt bot Platz für ein 
Hack-Center und die Workshops, für die viel 
Zeit eingeplant wurde. Jedoch mussten die- 
se in die Abendstunden rücken, in denen 
der Beamer gegen die Kernfusion am obe- 
ren Horizont wieder ankam. Erst dann konn- 
te sich die angesammelte Meute den Erläu- 
terungen zu PDF als coolen Datencontainer, 
Informationen zu GSM und UMTS, Fine- 
tuning von Firewalls und NAT-Netzen oder 
dem aktuellen Status zur 21C3-Planung [5] 
hingeben. Nur die obligatorische Brauereibe- 
sichtigung fand an einem Vormittag statt. 
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Die BlinkenArea-Crew stellte ihre Nach- 
bauten zu Blinkenlights und Arcade 
[6] ebenso aus, wie etliche neu- 
ere Basteleien, die stunden- 
lang zum Verweilen und 
Anschauen ein- 
luden. Das 
Event- 
Phone- 
Team 
[7] 

sorgte 
mit ihrer 
von etli- 
chen CCC- 
Veranstaltui 
gen bekannten 
Telefonanlage für 
die interne direkte 
Kommunikation mit 
tels DECT und Fest- 
netz und testete damit 
ein weiteres Mal das Setup 
für die Feldtauglichkeit. Beim 
CERT - dem Chaos Emergen- 
cy Response Team [8] - konnten 
sich von Mückenstichen und Son- 
nenbrand geplagte Hacker behan- 
deln lassen, für das leibliche Wohl 
sorgte ein über alle Stunden geöff- 
netes Büffet und das Grillteam, welches 
abends die Camper mit Würstchen, Kote 
lett und selbst Spanferkel am Spieß ver- 
sorgte. 



Eine dauerhafte Verbindung zum Internet konn- 
te ab dem zweiten Tag mittels eines Satelli- 
ten-Uplink bereitgestellt werden. Nach ein wenig 



f5 



Trickserei stand schließlich ein UDP- 
Tunnel zu einem Server nach Ber- 
lin, welcher das Camp mit Raten 
zwischen 30 und 60 kByte/s in 
I die Welt verband. Somit dürf- 
te auch bei künftigen Veran- 
staltungen 'in der Pampa' 
eine Möglichkeit gegeben 
sein, Internet bereit zu 
stellen. 



Dass Campen wie- 
der in Mode ist, 
konnte an der 
Größe der Zel- 
te festgestellt 
werden. 
^ Waren 
noch in 
den 
Vor- 
jah- 



HS' fl 




ren 
Iglu-Zel- 
te aka Hun- 
dehütte 'in', so 
standen diesmal etli- 
che mehrere Quadratmeter 
einnehmende Hauszelte auf dem 
Gelände. Schließlich sind diese klei- 
nen Camps ein optimaler Test für die grö- 
ßeren Camps. 

Ob eine ICMP 3 weiterhin auf dem bisherigen Gelän- 
de stattfinden wird, ist bei einer 
Besucherzuwachsrate von 100% 
fraglich. Die Kapazität des Plat- 
zes war schon nahezu erreicht. 
Doch können wir sicher sein, dass 
die Erlangener eine Lösung fin- 
den werden. 

[1] http://www.icmp2.de/ 
[2] http://www.brauerei-loscher.de/ 
[3] http://www.club-mate.de/ 
[4] http://erlangen.ccc.de/ 
[5] http:/ /www. ccc. de/congress/2004/ 
[6] http://www.blinkenlights.de/ 
[7] http://www.eventphone.de/ 
[8] http://www.c-e-r-t.de/ 
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Link State Routing - 
Optimized? 



von elektra <onelektra@gmx.net> 



Die Freenetwork Community auf dem Weg 
zum sich selbst organisierenden draht- 
losen Überallnetz. 

Militärisches Forschungsgebiet und 
intelligenter Staub 

Überall wird mit grossem Aufwand an der Technik sich 
selbst organisierender Funknetzwerke (Mesh-Clouds) 
geforscht. Die USA statten Soldaten mit PDAs aus, die 
sich auf dem Schlachtfeld drahtlos miteinander ver- 
netzen. Zur Überwachung gegnerischer Armeen, zur 
Steuerung von Minen und anderer Nettigkeiten sol- 
len drahtlos vernetzte Kleinstcomputer dienen - der 
'Smart-Dust'. Das Ziel der Entwicklung von Smart-Dust 
ist die Größe eines Sandkorns und ein Preis unter 5 
Dollar pro Stück - diese modernisierten Wanzen sollen 
u.a. in großen Mengen aus Flugzeugen abgeworfen 
werden. Die Pläne zur zivilen Nutzung des SmartDust 
beschränken sich auf Überwachungsaufgaben - auf 
Sensor-Netzwerke. 

Dynamisches Ad-Hoc-Routing im 

Community-Netzwerk 

Es ist wenig erstaunlich, dass bestimmte Implemen- 
tierungen von Mesh-Routing-Protokollen überhaupt 
nicht zugänglich sind. Meshing ist andererseits viel 
zu interessant um es Generälen und Spitzeldiens- 
ten zu überlassen. Bei Wlan-Communities, die ein frei 
zugängliches Überallnetz aufbauen wollen, wird an 
freien Implementierungen / Verbesserungen für Mesh- 
Routingprotokolle gebastelt. Campaign Urbana Wire- 
less (Cu-Wireless) ist dabei, HSLS (Hazy Sighted Link 
State routing protocol) zu implementieren. Die Frei- 
funk-Community in der Berliner C-base arbeitet daran, 
eine Linux-Implementierung von OLSR [1] zu erwei- 
tern und verbessern, die Andreas Tonnesen in Norwe- 
gen als Diplomarbeit für die UniK programmiert hat. 
Nach dem Abschluss des Diploms wäre die Implemen- 
tierung von Andreas ohne Unterstützung von Freifunk 
vielleicht in Schneewittchenschlaf gefallen, da Andreas 
selbst kein großes Interesse an Meshing hat. 

Dank der Arbeit von Thomas Lopatic gibt es inzwi- 
schen auch Ports für OS-X, FreeBSD und Windows. 
Inzwischen wurde eine veränderte Form von ETX 
(Erklärung gibt's im weiteren Text) in OLSR implemen- 
tiert. Soviel sei schon verraten: Der Freifunk-OLSR- 
Dämon weicht in vielen Punkten vom OLSR-Standard 




ab und ist nicht mehr kompatibel, wenn man die ent- 
sprechenden Features aktiviert. Das sollte man aber 
auf jeden Fall tun... 

Verschiedene Routingmechanismen für 
Mesh 

Die Probleme in einem mobilen Mesh sind zahlreich: 
Die Topologie ändert sich dauernd und Bandbrei- 
te ist immer knapp. Links weisen Paketverluste auf, 
sind nur kurzfristig vorhanden und ändern ihre Über- 
tragungsqualität ständig. Das verwendete Protokoll 
muss schnell reagieren - darf sich aber auch nicht kirre 
machen lassen... 

Proaktiv 

Bei proaktiven Protokollen wie OLSR, DSDV oder 
MMRP (Mobilemesh) wird versucht, immer alle Nodes, 
die Links und Routingpfade zwischen ihnen zu ken- 
nen, egal ob diese Routen gerade benötigt werden 
oder nicht. Diese Protokolle basieren auf Link-State- 
Algorithmen. 

Jeder am Mesh beteiligte Rechner pflegt eine Daten- 
bank in der die gesamte Struktur des Netzes festgehal- 
ten ist. Man kann davon ausgehen, dass proaktive Pro- 
tokolle in sehr großen Mesh-Netzen schlecht skalieren. 
Die Datenbanken werden sehr groß und die Menge 
der Informationen, die ausgetauscht werden müssen, 
um die augenblickliche Struktur des Netzes zu erfas- 
sen, wird zu einem Hemmschuh. Bei hochgradig mobi- 
len Nodes, die sich alle gleichzeitig in unterschiedli- 
che Richtungen bewegen können, wird die Datenbank 
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innerhalb kurzer Zeit wertlos und muss immer wieder 
neu angelegt werden. 

Aus diesem Grund eignet sich OSPF nicht. OSPF 
erstickt in dieser Situation am selbstgenerierten Traffic. 

Reaktiv 

Ein anderer Weg sind reaktive Protokolle wie DSR oder 
AODV. Um den Rechen- und Kommunikationsauf- 
wand zu minimieren, werden die Routingpfade nur bei 
Bedarf ermittelt, geprüft und gegebenenfalls neu ver- 
handelt. Braucht ein Teilnehmer einen Link zu einem 
entfernten Mesh-Knoten, verbreitet er einen Rou- 
te-Request (RREQ). Der RREQ wird so lange weiter- 
gereicht, bis er entweder beim gewünschten Node 
ankommt, oder auf einen Node trifft, der in seinem 
Cache bereits eine Route zum Zielrechner hat. Dieser 
sendet daraufhin einen Route Reply (RREP) auf dem 
Pfad wieder zurück, den der RREQ zuvor nahm. 

Steht die Route, spielen reaktive Routingalgorithmen 
so lange keine Rolle mehr bis einer der am Weiterrei- 
chen der Pakete beteiligten Rechner feststellt, dass die 
Route nicht mehr funktioniert. Dieser Rechner verbrei- 
tet eine Route-Error-Meldung (RERR) mit einer Lis- 
te aller Nodes, die nicht mehr über den defekten Link 
erreichbar sind. Damit der Routingmechanismus nicht 
ziellos innerhalb des Netzes verläuft oder gar End- 
losschleifen bildet wird eine sogenannte 'Destination 
Sequence Number' in den RREQ, RREP, RERR übertra- 
gen, anhand der das Protokoll erkennt ob es sich ziel- 
gerichtet verhält. 

Die Entwickler versprechen sich von ihrem Ansatz, dass 
er selbst mit mehreren zehntausend Netzteilnehmern 
noch funktionieren soll. Reaktive Protokolle brauchen 
länger um eine Verbindung aufzubauen, da diese erst 
bei Bedarf gesucht wird. 

Ausserdem existieren noch geographische oder hybride 
Protokolle. Geographische Protokolle routen anhand 
geographischer Koordinaten. Hybride Modelle wie ZRP 
arbeiten auf kurze Entfernung proaktiv und bei größe- 
rer Distanz reaktiv. 

Probleme, Probleme 

Die protokollbedingte Netzlast reduziert die nutzba- 
re Bandbreite 

Die Protokolle sollen schnellstmöglich die effektivs- 
te Route zu einem beliebigen Knoten im Mesh finden 
- ohne durch das ständige Übertragen von Informati- 
onen über die Struktur des Netzes eine große Netzlast 
(Overhead) zu erzeugen. Im schlimmsten Fall erstickt 
das Netz im selbst erzeugten Datenverkehr oder wird 
wesentlich gebremst. 

Die kürzeste Route zu finden ist nicht ausreichend 

Die meisten Protokolle berechnen die kürzeste Rou- 
te. Das ist nicht immer günstig. Je länger eine Funk- 
strecke zwischen zwei benachbarten Rechnern ist, des- 
to niedriger ist die Übertragungsrate. Der Paketverlust 



steigt und macht das erneute Übertragen von Daten 
notwendig. 

Eine Route, die über zwei Funkstrecken mit jeweils 90 
Prozent Paketverlust bei niedrigster Übertragungsra- 
te führt, ist kaum benutzbar. Eine Alternativroute, die 
stattdessen einen Sprung mehr macht und dafür Funk- 
strecken mit geringen Paketverlusten verwendet, kann 
bedeutend schneller sein. 

Protokolle, die derartige Erwägungen bei der Berech- 
nung der Routen berücksichtigen, sind im Durch- 
schnitt doppelt so performant wie jene, die einfach nur 
den kürzesten Pfad wählen. Die praktische Erfahrung 
zeigt, dass am Rande eines Mesh eine derartige Strate- 
gie darüber entscheidet ob man überhaupt noch eine 
brauchbare Verbindung hat oder nicht. 

Dazu braucht es eine Bewertung der Links (Metrik), 
der Routingalgorithmus muss die Routen anhand der 
Metrik berechnen. 

Am MIT wurde ein einfacher Algorithmus zur Ermitt- 
lung der Metrik entwickelt (ETX - Expected Transmis- 
sion Count), der dieser Anforderung Rechnung tragen 
soll. Bei ETX schicken die Netzknoten in einem fest- 
gelegten Intervall eine Anzahl UDP-Pakete. Die Emp- 
fänger können anhand der Anzahl der empfange- 
nen Pakete erkennen wie gut die Übertragung ist. ETX 
lässt sich leicht in vorhandene Protokolle integrieren. 
Die Idee, zusätzlichen UDP-Traffic zugenerieren gefällt 
überhaupt nicht. Deshalb hat der Freifunk-OLSRD 
eine abgewandelten ETX-Mechanismus: Es wird ein- 
fach eine Statistik über die empfangenen/verlorenge- 
gangenen Hello-Nachrichten der Nachbarn von jedem 
Node gebroadcastet - dieser Traffic entsteht bei OLSR 
sowieso. 

Fairness 

Das Routing muss bei der Berechnung der Routen ver- 
meiden, dass ein zu großer Teil des Datenverkehrs 
durch einen einzelnen oder wenige Netzwerkknoten 
geschickt wird und somit ein Flaschenhals entsteht, der 
unter der Netzlast zusammenbricht und den Daten- 
durchsatz behindert. Das lässt sich jedoch nicht immer 
vermeiden, etwa wenn es nur einen Link über einen 
einzelnen Netzknoten zwischen zwei Gruppen von 
Mesh-Nodes gibt. Links zu einem Flaschenhals haben 
aber ordentlich Paketloss und bekommen deshalb vom 
Freifunk-OLSRD eine schlechtere Metrik. 

IPv6 ist wichtig 

Die Konfiguration der Mesh-Rechner über DHCP ist 
ein schwieriges Unterfangen. Ohne eigene IP-Adresse 
funktioniert IP-basiertes Ad-Hoc-Routing nicht - man 
kann also nicht mit dem nächstgelegenen DHCP-Ser- 
ver kommunizieren, wenn dieser nicht in unmittelba- 
rer Reichweite ist. In kleineren Gruppen kann man die 
Adressen manuell zuweisen. Die IP-Vergabe in Berlin 
geschieht bislang über das Wiki olsr.freifunk.net. Mit 
IPv6 kann man den Prozess automatisieren. 
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Link State Routing - Optimized? 

OLSR versucht, die protokollbedingte Belastung im 
Netz zu minimieren, indem jeder Node nicht alle One- 
Hop-Neighbours zum redundanten Weiterleiten von 
Topologieinformationen verwendet. Einzelne One- 
Hop-Neighbours werden als sogenannte MultiPointRe- 
lays definiert - gerade so viele Neighbours, wie not- 
wendig sind um alle anderen Two-Hop-Neighbours 
zu erreichen. Nur diese MPRs werden zum Weiter- 
leiten von Topologieinformationen verwendet. OLSR 
hat ausserdem einen Hysterese-Mechanismus, der es 
wesentlich effektiver machen soll: Ein Link, der unre- 
gelmäßig funktioniert, und damit ein ständiges Neu- 
berechnen von Routen herbeiführen würde, wird nicht 
dauernd berücksichtigt. Gehen drei Hello-Nachrich- 
ten nacheinander verloren (Default-Einstellungen) wird 
der Link gelöscht. Genau dieses Gimmik bereitete aber 
beim Testen auf der WizardOfOS3 und im alltägli- 
chen Betrieb im Berlin-Mesh [2]Probleme. Durch die 
Hysterese wurden Links verworfen, die zwar schlecht, 
aber vorhanden waren. Dummerweise waren das aber 
des öfteren zufällig die MultiPointRelays, da OLSR 
die MPRs per Zufall bestimmt solange sie nicht aus 
der Hysterese fallen. Eine Hysterese kennt eben nur 
null oder eins - Ich hab nen Link, Ich hab ihn nicht... 
Das Resultat war eine lange Routingtabelle die immer 
wieder vollständig zusammenbrach um im nächsten 
Moment wieder komplett zu sein. Der Fix war: Hys- 
terese aus oder bremsen, größere Redundanz bei den 
Multipointrelais. OLSR zu optimieren bedeutete also 
die Optimierungen teilweise abzuschalten oder ihren 



Einfluss zu verkleinern. Der Gedanke der Entwickler 
den protokollbedingten Overhead zu verkleinern führ- 
te zu Instabilität. Multipointrelais könnten Ja schon 
Sinn machen - aber dann mit einer brauchbaren Metrik 
die die Wahl des MPR nicht dem Zufall überlässt. Des- 
wegen ist ETX seit olsr-0.48 in olsr implementiert. 

OLSR auf dem Weg zu .... 

Die WLAN-Community verzichtet inzwischen auf die 
Hysteresefunktion von OLSR, die sich per Konfigura- 
tionsdatei abschalten lässt. Es lässt sich eben theore- 
tisch kaum entscheiden was ein Mesh tatsächlich opti- 
miert. Die Bewertung der Links anhand des Paketloss 
liefert dagegen eine brauchbare Metrik, deren Einsatz 
in ersten Tests eine enorme Verbesserung gebracht 
hat. Multipointrelais bringen nur dann etwas wenn das 
Mesh tatsächlich sehr dicht ist, also wenn viele Nodes 
zahlreiche direkte Nachbarn haben. Bislang überschrei- 
tet aber kein bekanntes Mesh eine Anzahl von 50 
Nodes, die sich zu einer meshcloud zusammenschlies- 
sen. Im Moment ist die Implementierung von olsr.org 
IMHO die beste Basis für ein Communitynetzwerk. Bis 
zu welcher Teilnehmerzahl die gerade verfügbare Imp- 
lementierung skaliert, ist noch ungetestet. Dazu müs- 
sen die Meshes erstmal eine bestimmte Größe über- 
schreiten. Was vermutlich nicht lange dauern wird. 
Darauf freue ich mich schon. 

[1] http://www.olsr.org/ 
[2] http://olsr.freifunk.net/ 
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